event loops and Python?

Kragen Sitaker kragen at dnaco.net
Tue Mar 14 16:40:49 CET 2000

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

(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!
The power didn't go out on 2000-01-01 either.  :)

More information about the Python-list mailing list