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 i
On Jan 3, 10:09 am, Jérôme 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 place?
>
> Sa
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
Tue, 3 Jan 2012 07:03:08 -0800 (PST)
Adam Skutt a écrit:
> On Jan 3, 4:38 am, Jérôme 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: i
On Jan 3, 4:38 am, Jérôme 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 it's
done playing
On Jan 2, 11:53 pm, Cameron Simpson wrote:
> On 02Jan2012 19:16, Adam Skutt wrote:
> | On Jan 2, 8:44 pm, Cameron Simpson wrote:
> | > On 02Jan2012 20:31, Devin Jeanpierre wrote:
> | > | > I think that catching the exception is probably the most Pythonic way.
> | > |
> | > | It's the only corre
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 f
On Jan 3, 3:58 am, Chris Angelico wrote:
> On Tue, Jan 3, 2012 at 7:44 PM, Jérôme 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 t
On Jan 3, 3:44 am, Jérôme 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 you sho
Am 03.01.2012 14:40, schrieb Adam Skutt:
On Jan 3, 7:31 am, Heiko Wundram 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 by the operating
system
On Jan 3, 7:31 am, Heiko Wundram wrote:
> Am 03.01.2012 02:19, schrieb Adam Skutt:
>
> > On Jan 2, 6:09 pm, Jérôme 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 subproces
Am 03.01.2012 02:19, schrieb Adam Skutt:
On Jan 2, 6:09 pm, Jérôme 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 cannot be avoided, th
Tue, 3 Jan 2012 19:58:57 +1100
Chris Angelico a écrit:
> On Tue, Jan 3, 2012 at 7:44 PM, Jérôme 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 chan
On Tue, Jan 3, 2012 at 7:44 PM, Jérôme 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
> quarantines PID numbers
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 p
On 02Jan2012 19:16, Adam Skutt wrote:
| On Jan 2, 8:44 pm, Cameron Simpson wrote:
| > On 02Jan2012 20:31, Devin Jeanpierre 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 _i
On Jan 2, 8:44 pm, Cameron Simpson wrote:
> On 02Jan2012 20:31, Devin Jeanpierre 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 pr
On 02Jan2012 20:31, Devin Jeanpierre 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
> 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 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 send_signal
>> method
On Jan 2, 6:09 pm, 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 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 "/usr/lib/python2
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 "/usr/lib/python2.7/subprocess.py", line 1457, in send
22 matches
Mail list logo
