event loops and Python?

[Kragen Sitaker]

In article <200003120619.QAA11915 at piglet.dstc.edu.au>,
David Arnold  <davida at pobox.com> wrote:
>-->"Kragen" == Kragen Sitaker <kragen at dnaco.net> writes:
>  Kragen> Sorry, I meant, "This is bad if you're not running in a
>  Kragen> graphical environment."  I want to build an event-driven tty
>  Kragen> application.
>
>  Kragen> I guess I should start looking at how Tkinter does it :)
>
>i think tk uses the underlying Xt mainloop.  this is a part of the
>standard X distribution.  similar things are done by Gtk, for example.

Tk doesn't use Xt, and the standard X event-loop stuff (although not
the event-loop itself) is in Xlib, but the rest here is correct.

However, different Tks use different event loops.  The Perl/Tk
interface has changed its mind at least twice about whether the event
loop should be the standard Tk event loop or not.

>all it involves is a top-level loop based around select().  select
>takes a list of file objects and an (optional) timeout.  it will wait
>for activity on one of the files, or the expiry of the timeout, before
>returning control to your code.

Or a signal.  I've written select() loops before.

>you can easily do this all in Python (on Unix.  win32's select()
>doesn't work for anything other than sockets, and you'll have to use
>WaitForMultipleObjects() or something).

I found that I could do everything but SIGCHLD handling safely in
Perl.  I suspect the same thing will be true of Python.

I don't care much about Win32 for now.

>it's not clear exactly what you want to do, but a quick cruise of the
>X or Gtk (actually, i think it's in the GDK) mainloops will get you
>started.

Well, thanks for the tip.  :)

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.

Another is that handling signals safely in Perl is tough, and I
assume the same thing is true of Python.

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.
-- 
<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.  :)