On Oct 1, 10:35 am, Antoine Pitrou wrote:
> On Thu, 30 Sep 2010 07:01:09 -0700 (PDT)
>
> Jean-Paul Calderone wrote:
>
> > But signal dispositions are inherited by child processes. So you run
> > ping from your short Python program, and it inherits SIGPIPE being
> > ignored. And it's written in
On Thu, 30 Sep 2010 07:01:09 -0700 (PDT)
Jean-Paul Calderone wrote:
>
> But signal dispositions are inherited by child processes. So you run
> ping from your short Python program, and it inherits SIGPIPE being
> ignored. And it's written in C, not Python, so when it writes to the
> pipe, there'
(Sending again to the list, I mailed Jean-Paul off-list by mistake, sorry).
On Thu, Sep 30, 2010 at 4:01 PM, Jean-Paul Calderone
wrote:
> You can fix this by resetting the signal disposition of SIGPIPE for
> the ping process:
>
> #!/usr/bin/python
> import signal
>
> def reset():
>
On Sep 30, 9:08 am, David wrote:
> On Wed, Sep 29, 2010 at 6:49 PM, John Nagle wrote:
> > Python's signal handling for multithread and multiprocess programs
> > leaves something to be desired.
>
> Thanks for the confirmation (that I'm not missing something obvious).
>
> I've reported a bug for
On Wed, Sep 29, 2010 at 6:49 PM, John Nagle wrote:
> Python's signal handling for multithread and multiprocess programs
> leaves something to be desired.
>
Thanks for the confirmation (that I'm not missing something obvious).
I've reported a bug for this behavior in the Python issue tracker.
On 9/29/2010 7:24 AM, David wrote:
Hi there, I have a strange situation.
If I do this:
1. Make a script /tmp/test.py on a remote server, with this contents:
#!/usr/bin/python
from subprocess import check_call
Python's signal handling for multithread and multiprocess programs
leaves someth
Hi there, I have a strange situation.
If I do this:
1. Make a script /tmp/test.py on a remote server, with this contents:
#!/usr/bin/python
from subprocess import check_call
check_call(['ping', 'www.google.com'])
2. Call the script like this over SSH:
ssh r...@testbox /tmp/test.py
3. Interrup
