event loops and Python?
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
>| 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