Mon, 2 Jan 2012 19:16:50 -0800 (PST)
Adam Skutt a écrit:
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. Hence why you should
avoid sending the signal in the first place:
On Tue, Jan 3, 2012 at 7:44 PM, Jérôme jer...@jolimont.fr wrote:
If so, I don't see how I can protect myself from that. Checking the process
is alive and then hoping that the time interval for the race condition is so
small that there are few chances for that to happen (because the OS
Tue, 3 Jan 2012 19:58:57 +1100
Chris Angelico a écrit:
On Tue, Jan 3, 2012 at 7:44 PM, Jérôme jer...@jolimont.fr wrote:
If so, I don't see how I can protect myself from that. Checking the
process is alive and then hoping that the time interval for the race
condition is so small that there
Am 03.01.2012 02:19, schrieb Adam Skutt:
On Jan 2, 6:09 pm, Jérômejer...@jolimont.fr wrote:
What is the clean way to avoid this race condition ?
The fundamental race condition cannot be removed nor avoided. Ideally,
avoid the need to send the subprocess a signal in the first place. If
it
On Jan 3, 7:31 am, Heiko Wundram modeln...@modelnine.org wrote:
Am 03.01.2012 02:19, schrieb Adam Skutt:
On Jan 2, 6:09 pm, Jérômejer...@jolimont.fr wrote:
What is the clean way to avoid this race condition ?
The fundamental race condition cannot be removed nor avoided. Ideally,
avoid
Am 03.01.2012 14:40, schrieb Adam Skutt:
On Jan 3, 7:31 am, Heiko Wundrammodeln...@modelnine.org wrote:
Yes, it can be avoided, that's what the default SIGCHLD-handling
(keeping the process as a zombie until it's explicitly collected by a
wait*()) is for, which forces the PID not to be reused
On Jan 3, 3:44 am, Jérôme jer...@jolimont.fr wrote:
Mon, 2 Jan 2012 19:16:50 -0800 (PST)
Adam Skutt a écrit:
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. Hence why
On Jan 3, 3:58 am, Chris Angelico ros...@gmail.com wrote:
On Tue, Jan 3, 2012 at 7:44 PM, Jérôme jer...@jolimont.fr wrote:
If so, I don't see how I can protect myself from that. Checking the process
is alive and then hoping that the time interval for the race condition is so
small that
Tue, 3 Jan 2012 06:12:59 -0800 (PST)
Adam Skutt a écrit:
The conservative approach is to use another IPC mechanism to talk to
the process, such as a pipe or a socket. Why are you trying to send
the child process SIGINT in the first place?
Say, you've got an application that plays a sound for
On Jan 2, 11:53 pm, Cameron Simpson c...@zip.com.au wrote:
On 02Jan2012 19:16, Adam Skutt ask...@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
On Jan 3, 4:38 am, Jérôme jer...@jolimont.fr wrote:
I have an application that can spawn a subprocess to play a beep. I want it
to kill the subprocess when exiting.
Why? You shouldn't need to send a signal to tell the process to
terminate: it should terminate when its stdin is closed or when
Tue, 3 Jan 2012 07:03:08 -0800 (PST)
Adam Skutt a écrit:
On Jan 3, 4:38 am, Jérôme jer...@jolimont.fr wrote:
I have an application that can spawn a subprocess to play a beep. I want
it to kill the subprocess when exiting.
Why? You shouldn't need to send a signal to tell the process to
Tue, 3 Jan 2012 17:24:44 +0100
Jérôme a écrit:
Too many libraries do too many questionable things with signal handlers
so I find it much safer and easier just to avoid the damn things whenever
possible.
My small program _seems to_ work with the dirty hacks I already exposed.
Yet, I'd
On Jan 3, 10:09 am, Jérôme jer...@jolimont.fr wrote:
Tue, 3 Jan 2012 06:12:59 -0800 (PST)
Adam Skutt a écrit:
The conservative approach is to use another IPC mechanism to talk to
the process, such as a pipe or a socket. Why are you trying to send
the child process SIGINT in the first
Tue, 3 Jan 2012 09:58:35 -0800 (PST)
Adam Skutt a écrit:
If you're really insistent on using the sox(1) command-line tools to play
your sounds, then you'll have to send SIGINT or SIGTERM in order to tell it
to terminate (which can be done just by calling the terminate() method).
Which is
On 02/01/2012 23:09, Jérôme wrote:
Hi all.
When a subprocess is running, it can be sent a signal with the send_signal
method :
process = Popen( args)
process.send_signal(signal.SIGINT)
If the SIGINT is sent while the process has already finished, an error is
raised :
File
On Jan 2, 6:09 pm, Jérôme jer...@jolimont.fr wrote:
Hi all.
When a subprocess is running, it can be sent a signal with the send_signal
method :
process = Popen( args)
process.send_signal(signal.SIGINT)
If the SIGINT is sent while the process has already finished, an error is
raised :
I think that catching the exception is probably the most Pythonic way.
It's the only correct way.
-- Devin
On Mon, Jan 2, 2012 at 6:51 PM, MRAB pyt...@mrabarnett.plus.com wrote:
On 02/01/2012 23:09, Jérôme wrote:
Hi all.
When a subprocess is running, it can be sent a signal with the
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,
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
On 02Jan2012 19:16, Adam Skutt ask...@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.
21 matches
Mail list logo
