Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #18370
| Date | 2012-01-03 15:53 +1100 |
|---|---|
| From | Cameron Simpson <cs@zip.com.au> |
| Subject | Re: Avoid race condition with Popen.send_signal |
| References | <63817f2b-ccf8-4d7d-92a6-c1d622986d8a@j10g2000vbe.googlegroups.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.4329.1325566392.27778.python-list@python.org> (permalink) |
On 02Jan2012 19:16, Adam Skutt <askutt@gmail.com> wrote: | On Jan 2, 8:44 pm, Cameron Simpson <c...@zip.com.au> wrote: | > On 02Jan2012 20:31, Devin Jeanpierre <jeanpierr...@gmail.com> wrote: | > | > I think that catching the exception is probably the most Pythonic way. | > | | > | It's the only correct way. | > | > Indeed, but be precise - chek that it _is_ error 3, or more portably, | > errno.ESRCH. POSIX probably mandates that that is a 3, but the symbol | > should track the local system if it differs. Example: | | No. It is possible (however unlikely) for EPERM to be legitimately | returned in this case. Anything other than EINVAL should be | interpreted as "The child process is dead". Sure. I was more taking the line: catch and accept only the specific errors you understand. Of course he can catch EPERM also. But any other variant should at the least generate a warning to stderr or a log - it is _unexpected_. I take your point that reraising the exception may be overkill for failed signal delivery (if that was your point). But I am arguing for being very careful about what you silently pass as an ok thing. | Hence why you should | avoid sending the signal in the first place: the situations where you | don't run the risk of possibly killing an innocent bystander are | pretty narrow. While unlikely on modern UNiX and Linux, IMO it's best | to avoid the issue altogether whenever possible. Fair enough too. But sometimes you need to nail a rogue child. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Death is life's way of telling you you've been fired. - R. Geis
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Avoid race condition with Popen.send_signal Cameron Simpson <cs@zip.com.au> - 2012-01-03 12:44 +1100
Re: Avoid race condition with Popen.send_signal Adam Skutt <askutt@gmail.com> - 2012-01-02 19:16 -0800
Re: Avoid race condition with Popen.send_signal Cameron Simpson <cs@zip.com.au> - 2012-01-03 15:53 +1100
Re: Avoid race condition with Popen.send_signal Adam Skutt <askutt@gmail.com> - 2012-01-03 06:52 -0800
Re: Avoid race condition with Popen.send_signal Jérôme <jerome@jolimont.fr> - 2012-01-03 09:44 +0100
Re: Avoid race condition with Popen.send_signal Adam Skutt <askutt@gmail.com> - 2012-01-03 06:12 -0800
Re: Avoid race condition with Popen.send_signal Jérôme <jerome@jolimont.fr> - 2012-01-03 16:09 +0100
Re: Avoid race condition with Popen.send_signal Adam Skutt <askutt@gmail.com> - 2012-01-03 09:58 -0800
Re: Avoid race condition with Popen.send_signal Jérôme <jerome@jolimont.fr> - 2012-01-03 19:45 +0100
Re: Avoid race condition with Popen.send_signal Chris Angelico <rosuav@gmail.com> - 2012-01-03 19:58 +1100
Re: Avoid race condition with Popen.send_signal Adam Skutt <askutt@gmail.com> - 2012-01-03 06:20 -0800
Re: Avoid race condition with Popen.send_signal Jérôme <jerome@jolimont.fr> - 2012-01-03 10:38 +0100
Re: Avoid race condition with Popen.send_signal Adam Skutt <askutt@gmail.com> - 2012-01-03 07:03 -0800
Re: Avoid race condition with Popen.send_signal Jérôme <jerome@jolimont.fr> - 2012-01-03 17:24 +0100
Re: Avoid race condition with Popen.send_signal Jérôme <jerome@jolimont.fr> - 2012-01-03 18:25 +0100
csiph-web