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.
| 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.
| 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
Donn Cave, donn at u.washington.edu