event loops and Python?

[Kragen Sitaker]

In article <8aj8if$dk2$1 at nntp6.u.washington.edu>,
Donn Cave  <donn at u.washington.edu> wrote:
>Quoth kragen at dnaco.net (Kragen Sitaker):
>...
>| There are a few things that were bothering me.
>|
>| One is that you can't have two event loops in the same thread.  Event
>| loops are one of the few things you can only have one of.  Accordingly,
>| if you have two pieces of code designed to run from two different event
>| loops, and you want to build a program containing both, your choices
>| are somewhat restricted --- modify one to work with the other's event
>| loop, run them in different threads, or give up.
>|
>| So a standard event loop, or at least a standard event-loop API,
>| for all event-loop-based Python applications would be very useful.
>
>Sounds like asyncore is running unopposed for that, so far.

Nobody had yet mentioned asyncore in this thread.  Thanks!  That's
exactly the kind of thing I was looking for.

Asyncore doesn't look perfect from an efficiency point of view, but it
looks like it might be simpler for a client to use than a raw
event-loop API.

>| Another is that handling signals safely in Perl is tough, and I
>| assume the same thing is true of Python.
>
>True, and I say good riddance.  Signals are easier to use in C, but
>are really appropriate for only low level stuff, in my opinion -
>for example from a software engineering point of view, try to get your
>two pieces of code to cooperate over signals, or even protect themselves
>from each other's use of signals.

In Unix, there are things that can only be done in a non-blocking
fashion by handling signals:  SIGCHLD when a child process dies, for
instance.  And it's probably a good idea to handle SIGTERM and SIGWINCH.

Treating those signals as events like any other can simplify your life
drastically.

(There are cases where you really do need interrupt-style signals, but
in an event-loop-based application with quick event-handlers, SICHLD,
SIGTERM, and SIGWINCH are not among them.)

>| Another is that, while I'm comfy with writing select()-based
>| event loops in C, I'm not particularly comfy with writing C code that
>| interfaces with the Python interpreter, particularly at such an
>| intimate level.  I was hoping I could put that off until later.
>|
>| Enough English.  Now it is time for me to write code before posting more.
>
>Eek, use Python's select() function, if you don't use asyncore!  The
>Python select() implementation is much more convenient

I'll be writing a mailer.  I'll spawn off child processes to edit
mail.  wait() is not an option.  Handing SIGCHLD is necessary.
-- 
<kragen at pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)