Sorry. I was on holiday, and then buried this when sorting out my
thousands of Emails on my return, partly because I had to look up the
information!
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote:
| afaik the kernel only sends signals to threads that don't have them
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote:
Michael Hudson schrieb:
According to [1], all python needs to do to avoid this problem is
block all signals in all but the main thread;
Argh, no: then people who call system() from non-main threads end up
running
- http://www.python.org/sf/1564547
--
Gustavo J. A. M. Carneiro
The universe is always one step beyond logic.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Martin v. Löwis [EMAIL PROTECTED] writes:
Michael Hudson schrieb:
According to [1], all python needs to do to avoid this problem is
block all signals in all but the main thread;
Argh, no: then people who call system() from non-main threads end up
running subprocesses with all signals
On 9/12/06, Adam Olsen [EMAIL PROTECTED] wrote:
On 9/12/06, Gustavo Carneiro [EMAIL PROTECTED] wrote:
On 9/12/06, Adam Olsen [EMAIL PROTECTED] wrote:
My previous mention of using a *single* flag may survive corruption
simply because we can tolerate false positives. Signal handlers would
Adam Olsen wrote:
That brings you back to how you access the flags variable.
The existing signal handler sets a flag, doesn't it?
So it couldn't be any more broken than the current
implementation.
If we get too paranoid about this, we'll just end
up deciding that signals can't be used for
On 9/12/06, Greg Ewing [EMAIL PROTECTED] wrote:
Adam Olsen wrote:
That brings you back to how you access the flags variable.
The existing signal handler sets a flag, doesn't it?
So it couldn't be any more broken than the current
implementation.
If we get too paranoid about this, we'll
On 9/12/06, Adam Olsen [EMAIL PROTECTED] wrote:
On 9/12/06, Greg Ewing [EMAIL PROTECTED] wrote:
Adam Olsen wrote:
That brings you back to how you access the flags variable.
The existing signal handler sets a flag, doesn't it?
So it couldn't be any more broken than the current
On 9/12/06, Gustavo Carneiro [EMAIL PROTECTED] wrote:
On 9/12/06, Adam Olsen [EMAIL PROTECTED] wrote:
My previous mention of using a *single* flag may survive corruption
simply because we can tolerate false positives. Signal handlers would
write 0x, the poll loop would check if
On 9/12/06, Gustavo Carneiro [EMAIL PROTECTED] wrote:
On 9/12/06, Adam Olsen [EMAIL PROTECTED] wrote:
My previous mention of using a *single* flag may survive corruption
simply because we can tolerate false positives. Signal handlers would
write 0x, the poll loop would check if
Nick Maclaren schrieb:
(coment by Arjan van de Ven):
| afaik the kernel only sends signals to threads that don't have them
blocked.
| If python doesn't want anyone but the main thread to get signals, it
should just
| block signals on all but the main thread and then by nature, all
signals
Michael Hudson schrieb:
According to [1], all python needs to do to avoid this problem is
block all signals in all but the main thread;
Argh, no: then people who call system() from non-main threads end up
running subprocesses with all signals masked, which breaks other
things in very
On 9/11/06, Adam Olsen [EMAIL PROTECTED] wrote:
Now on to my new proposal. I do still use write(). If you can't
accept that I think we should rip signals out entirely, just let them
kill the process. Not a reliable feature of any OS.
We create a single pipe and use it for all signals. We
On 9/11/06, Greg Ewing [EMAIL PROTECTED] wrote:
Gustavo Carneiro wrote:
The only potential problem left is that, by changing the pipe file
descriptor to non-blocking mode we can only write as many bytes to it
without reading from the other side as the pipe buffer allows. If a
large
Jan Kanis wrote:
However, PyGTKs problem does get
solved, as long as there is _a_ thread that returns to the interpreter
within some timeframe. It seems plausible that this will happen.
I don't see that this makes the situation much better,
as it just shifts the need for polling to another
On 9/9/06, Nick Maclaren [EMAIL PROTECTED] wrote:
I can't honestly promise to put any time into this in the forseeable
future, but will try (sometime). If anyone wants to tackle this,
please ask me for comments/help/etc.
It took me a while to realize just what was wrong with my proposal,
but
I was hoping to have stopped, but here are a few comments.
I agree with Jan Kanis. That is the way to tackle this one.
Adam Olsen [EMAIL PROTECTED] wrote:
I don't think we should let this die, at least not yet. Nick seems to
be arguing that ANY signal handler is prone to random
On 9/9/06, Jan Kanis [EMAIL PROTECTED] wrote:
At the risk of waking up a thread that was already declared dead, but
perhaps this is usefull.
So, what happens is pythons signal handler sets a flag and registrers a
callback. Then the main thread should check the flag and make the callback
to
On 9/9/06, Adam Olsen [EMAIL PROTECTED] wrote:
On 9/8/06, Adam Olsen [EMAIL PROTECTED] wrote:
Ensuring modifications to that array are atomic would be tricky, but I
think it would be doable if we use a read-copy-update approach (with
two alternating signal handler functions). Not sure how
On 9/9/06, Nick Maclaren [EMAIL PROTECTED] wrote:
I was hoping to have stopped, but here are a few comments.
I agree with Jan Kanis. That is the way to tackle this one.
Alas, it doesn't work in practice, as I already replied.
[...]
Despite the implication, the code of Py_AddPendingCall is
On Sat, 09 Sep 2006 12:59:23 +0200, Gustavo Carneiro
[EMAIL PROTECTED] wrote:
On 9/9/06, Jan Kanis [EMAIL PROTECTED] wrote:
However, PyGTKs problem does get
solved, as long as there is _a_ thread that returns to the interpreter
within some timeframe. It seems plausible that this will
On 9/8/06, Jan Kanis [EMAIL PROTECTED] wrote:
At the risk of waking up a thread that was already declared dead, but
perhaps this is usefull.
I don't think we should let this die, at least not yet. Nick seems to
be arguing that ANY signal handler is prone to random crashes or
corruption (due to
On 9/8/06, Adam Olsen [EMAIL PROTECTED] wrote:
Ensuring modifications to that array are atomic would be tricky, but I
think it would be doable if we use a read-copy-update approach (with
two alternating signal handler functions). Not sure how to ensure
there's no currently running signal
Gustavo Carneiro [EMAIL PROTECTED] writes:
On 9/4/06, Nick Maclaren [EMAIL PROTECTED] wrote:
Gustavo Carneiro [EMAIL PROTECTED] wrote:
I am now thinking of something along these lines:
typedef void (*PyPendingCallNotify)(void *user_data);
PyAPI_FUNC(void)
Adam Olsen [EMAIL PROTECTED] wrote:
On 9/4/06, Gustavo Carneiro [EMAIL PROTECTED] wrote:
Now, we've had this API for a long time already (at least 2.5
years). I'm pretty sure it works well enough on most *nix systems.
Event if it works 99% of the times, it's way better than *failing*
On 9/5/06, Adam Olsen [EMAIL PROTECTED] wrote:
On 9/4/06, Gustavo Carneiro [EMAIL PROTECTED] wrote:
Now, we've had this API for a long time already (at least 2.5
years). I'm pretty sure it works well enough on most *nix systems.
Event if it works 99% of the times, it's way better than
Gustavo Carneiro [EMAIL PROTECTED] wrote:
Anyway, I was speaking hypothetically. I'm pretty sure writing to a
pipe is async signal safe. It is the oldest trick in the book,
everyone uses it. I don't have to see a written signed contract to
know that it works.
Ah. Well, I can assure you
Nick Maclaren wrote:
Gustavo Carneiro [EMAIL PROTECTED] wrote:
Anyway, I was speaking hypothetically. I'm pretty sure writing to a
pipe is async signal safe. It is the oldest trick in the book,
everyone uses it. I don't have to see a written signed contract to
know that it works.
Ah.
Johan Dahlin wrote:
Nick Maclaren wrote:
Gustavo Carneiro [EMAIL PROTECTED] wrote:
I'm pretty sure writing to a pipe is async signal safe. It is the
oldest trick in the book, everyone uses it. I ... know that it works.
Ah. Well, I can assure you that it's not the oldest trick in the
Johan Dahlin [EMAIL PROTECTED] wrote:
Are you saying that we should let less commonly used platforms dictate
features and functionality for the popular ones?
I mean, who uses HP/UX, SCO and [insert your favorite flavor] as a modern
desktop system where this particular bug makes a difference?
On Saturday 02 September 2006 22:10, Gustavo Carneiro wrote:
According to [1], all python needs to do to avoid this problem is
block all signals in all but the main thread; then we can guarantee
signal handlers are always called from the main thread, and pygtk
doesn't need a timeout.
But I
Gustavo Carneiro [EMAIL PROTECTED] writes:
According to [1], all python needs to do to avoid this problem is
block all signals in all but the main thread;
Argh, no: then people who call system() from non-main threads end up
running subprocesses with all signals masked, which breaks other
Gustavo Carneiro [EMAIL PROTECTED] wrote:
That's a very good point; I wasn't aware that child processes
inherited the signals mask from their parent processes.
That's one of the few places where POSIX does describe what happens.
Well, usually. You really don't want to know what happens when
Chris McDonough [EMAIL PROTECTED] wrote:
Would adding an API for sigprocmask help here?
No. sigprocmask is a large part of the problem.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: [EMAIL PROTECTED]
On Tuesday 05 September 2006 00:05, Nick Maclaren wrote:
Anthony Baxter isn't exaggerating the problem, despite what you may
think from his posting.
If the SF bugtracker had a better search interface, you could see why I have
such a bleak view of this area of Python. What's there now *mostly*
On 9/4/06, Nick Maclaren [EMAIL PROTECTED] wrote:
Gustavo Carneiro [EMAIL PROTECTED] wrote:
I am now thinking of something along these lines:
typedef void (*PyPendingCallNotify)(void *user_data);
PyAPI_FUNC(void) Py_AddPendingCallNotify(PyPendingCallNotify callback,
void
On Tuesday 05 September 2006 00:52, Gustavo Carneiro wrote:
3. Signals can be delivered to any thread, let's assume (because
of point #1 and not others not mentioned) that we have no control over
which threads receive which signals, might as well be random for all
we know;
Note that
On Mon, 04 Sep 2006 15:05:56 +0100, Nick Maclaren [EMAIL PROTECTED] wrote:
Gustavo Carneiro [EMAIL PROTECTED] wrote:
That's a very good point; I wasn't aware that child processes
inherited the signals mask from their parent processes.
That's one of the few places where POSIX does describe what
Gustavo Carneiro wrote:
OK, let's review what we know about current python, signals, and threads:
1. Python launches threads without touching sigprocmask;
2. Python installs signal handlers for all signals;
3. Signals can be delivered to any thread, let's assume (because
of
Gustavo Carneiro [EMAIL PROTECTED] wrote:
You guys are tough customers to please. I am just trying to solve a
problem here, not create a new one; you have to believe me.
Oh, I believe you.
Look at it this way. You are trying to resolve the problem that your
farm is littered with cluster
Jean-Paul Calderone wrote:
PyGTK would presumably implement its pending call callback by writing a
byte to a pipe which it is also passing to poll().
But doing that in a signal handler context invokes undefined behaviour
according to POSIX.
--
David Hopwood [EMAIL PROTECTED]
On Mon, 04 Sep 2006 17:24:56 +0100, David Hopwood [EMAIL PROTECTED] wrote:
Jean-Paul Calderone wrote:
PyGTK would presumably implement its pending call callback by writing a
byte to a pipe which it is also passing to poll().
But doing that in a signal handler context invokes undefined behaviour
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Mon, 04 Sep 2006 17:24:56 +0100,
David Hopwood [EMAIL PROTECTED]
der.co.uk wrote:
Jean-Paul Calderone wrote:
PyGTK would presumably implement its pending call callback by writing a
byte to a pipe which it is also passing to poll().
But
On Mon, 04 Sep 2006 18:18:41 +0100, Nick Maclaren [EMAIL PROTECTED] wrote:
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Mon, 04 Sep 2006 17:24:56 +0100,
David Hopwood [EMAIL PROTECTED]
der.co.uk wrote:
Jean-Paul Calderone wrote:
PyGTK would presumably implement its pending call callback
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
Thanks for expounding. Given that it is basically impossible to do
anything useful in a signal handler according to the relevant standards
(does Python's current signal handler even avoid relying on undefined
behavior?), how would you suggest
In GLib we have a child watch notification feature that relies on
the following signal handler:
static void
g_child_watch_signal_handler (int signum)
{
child_watch_count ++;
if (child_watch_init_state == CHILD_WATCH_INITIALIZED_THREADED)
{
write (child_watch_wake_up_pipe[1], B,
On 9/4/06, Nick Maclaren [EMAIL PROTECTED] wrote:
Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Mon, 04 Sep 2006 17:24:56 +0100,
David Hopwood [EMAIL PROTECTED]
der.co.uk wrote:
Jean-Paul Calderone wrote:
PyGTK would presumably implement its pending call callback by writing a
byte
On 9/4/06, Gustavo Carneiro [EMAIL PROTECTED] wrote:
Now, we've had this API for a long time already (at least 2.5
years). I'm pretty sure it works well enough on most *nix systems.
Event if it works 99% of the times, it's way better than *failing*
*100%* of the times, which is what happens
Would adding an API for sigprocmask help here?
(Although it has been tried before -- http://mail.python.org/
pipermail/python-dev/2003-February/033016.html and died in the womb
due to threading-related issues -- http://mail.mems-exchange.org/
durusmail/quixote-users/1248/)
- C
On Sep 2,
We have to resort to timeouts in pygtk in order to catch unix signals
in threaded mode.
The reason is this. We call gtk_main() (mainloop function) which
blocks forever. Suppose there are threads in the program; then any
thread can receive a signal (e.g. SIGINT). Python catches the signal,
but
Gustavo Carneiro [EMAIL PROTECTED] wrote:
We have to resort to timeouts in pygtk in order to catch unix signals
in threaded mode.
A common defect of modern designs - TCP/IP is particularly objectionable
in this respect, but that battle was lost and won over two decades ago :-(
The reason is
On 9/2/06, Nick Maclaren [EMAIL PROTECTED] wrote:
According to [1], all python needs to do to avoid this problem is
block all signals in all but the main thread; then we can guarantee
signal handlers are always called from the main thread, and pygtk
doesn't need a timeout.
1) That page is
Gustavo Carneiro [EMAIL PROTECTED] wrote:
Oh, sorry, here's the comment:
(coment by Arjan van de Ven):
| afaik the kernel only sends signals to threads that don't have them blocked.
| If python doesn't want anyone but the main thread to get signals, it
should just
| block signals on
53 matches
Mail list logo
