=?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
>
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
-> 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:
http://mail.python.org/ma
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 h
"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 a
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
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, al
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 ch
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 ch
"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 curr
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 th
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 thi
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 anyt
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 number of signals arrive very quickly, that buffer ma
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
> >
On 9/11/06, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 9/11/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > This much would allow a GUI's poll loop to wake up when there is a
> > signal, and give control back to the python main loop, which could
> > then read off the signals and queue up their
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
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,
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 anoth
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 w
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_AddPendingCa
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
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
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 rand
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
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
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 actually do something with the signal. However
"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) Py_AddPend
On 9/5/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
[...]
> Even if write is atomic, there are gotchas. What if the interrupted
> code is doing something to that file at the time? Are you SURE that
> an unexpected operation on it (in the same thread) won't cause the
> library function of program
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 differ
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 oldes
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 work
"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 assu
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 bett
"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 tha
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 ha
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 b
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",
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 sugge
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 pend
Jean-Paul Calderone wrote:
> 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 sign
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
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 b
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]>
"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 clu
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
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
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 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,
> > vo
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*
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 PROTECTE
"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
On 9/4/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> "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
>
"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
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.
> B
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, 2006
"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 si
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
"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 re
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 do
60 matches
Mail list logo
