RetroSearch Browse

Sat Dec 8 22:33:26 CET 2007 · https://mail.python.org/pipermail/python-dev/2007-December/075635.html

On Dec 8, 2007 1:38 PM, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> On 08/12/2007, Guido van Rossum <guido at python.org> wrote:
> > On Dec 8, 2007 9:57 AM, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> > > Which is the best solution?  I think my patch fixes two problems: 1. the
> > > need to have a FD to wake up poll() (t o fix the problem with what we
> are
> > > discussing in this thread), and 2. make Python's signal handling more
> > > reliable (not 100% reliable because it doesn't handle longer bursts of
> > > signals than the pipe buffer can take, but at least is race free).
> >
> > I think it's okay to drop signals if too many come. The FD should be
> > put in non-blocking mode so the signal handler won't block forever.
> > Does Unix even promise that a signal gets delivered twice if it gets
> > sent quickly twice in a row?
>
> Good point.

Note that we may drop a new signal, not the same one we got several
times.  I don't know if Unix will do that.  Then again, I've been
unable to find documentation promising it'd deliver any signal at all.

-- 
Adam Olsen, aka Rhamphoryncus

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-December/075635.html below:

[Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).