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

[Gustavo Carneiro]

On 11/12/2007, Guido van Rossum <guido at python.org> wrote:
>
> On Dec 10, 2007 4:07 PM, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> > On 10/12/2007, Guido van Rossum <guido at python.org> wrote:
> >
> > > > Adam & I are now on #python-dev. Can you join?
> > >
> > > I think we successfully resolved this. Adam Olsen will produce a patch
> > > that allows one to specify a single file descriptor to which a zero
> > > byte will be written by the C-level signal handler. Twisted and PyGTK
> > > will have to coordinate about this file descriptor. Glyph believes
> > > this is possible and sufficient.
> >
> > Great that a solution was found at last.  But to be honest I don't
> > understand why my patch (the second one) is not good.  Why is it
> preferable
> > for libraries to provide their own file descriptor?
>
> So the app is in charge of creating the pipe if it wants it.
>
> We expect that if the pipe is always created, apps that assume only
> fds 0, 1 and 2 are open may get confused or accidentally close it,
> etc.


It's the first time I hear about this problem, but sounds plausible.

> Are people concerned about the overhead of always creating a pipe even it
> > may not be used?  Always creating a pipe would at least avoid the need
> for
> > any "coordination" between PyGTK and Twisted.
>
> I don't think that anyone involved though the need for coordination
> was an issue.


Yeah.   Thinking again on this, I don't think this is a problem, not because
coordination between PyGTK and Twisted can be done, but because no such
coordination is needed.  PyGTK can have one FD, Twisted another FD.  Since
only one of the main loops can be running, there's no conflict.

Please let this rest. We have a solution.


Sure.  :-)

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20071211/3f9f906c/attachment.htm