Stackless + GUI (was: RE: [Stackless] Re: [Python-Dev] uthread st rawman)

[Mike Fletcher]

Just a note:
	The GUI systems have a number of potential mainloop mechanisms.  In
wxPython and Tkinter this seems to be 1) the "application" mainloop and 2)
modal or "waited" dialogues/windows.  Those recursive mainloops are a
problem (I haven't figured out how to override them in wxPython), as are
"blocked" micro-threads in callbacks.

That said, I find that programming GUIs with micro-threads is really quite
clean feeling.  To handle an event, spawn a micro-thread to do the
"grunt-work" processing and then immediately return from the callback (all
callback handlers run (atomically) in the same micro-thread, they can spawn
new micro-threads, they just can't "yield" to them (i.e. block) without
disabling the mainloop).

The biggest problem is when your handler wants to "block/wait" on another
window, where you want to suspend the main mainloop while you run the
recursive mainloop.  I have to do that with a (hacky) thing where I spawn a
uthread to wait for the other dialog and return from the initiating handler.
That results in _not_ freezing the parent frame. (I have no explanation why
you can't just block the mainloop, it just doesn't seem to work when I try
it).

The second biggest problem is, of course, blocking C code that winds up
blocking the whole micro-threading system (that's what the recursive
mainloops are), but this is a more general problem than just GUIs.  Could be
a primitive C "consider my uthread blocked" call would be possible, with C
libs calling that before any potentially blocking calls?  Hmm, sounds like
yielding the global interpreter lock...

Micro-threads, not just for servers any more...
Mike

-----Original Message-----
From: Guido van Rossum [mailto:guido at python.org]
Sent: Tuesday, November 07, 2000 9:58 PM
To: Greg Ewing
Cc: python-dev at python.org; stackless at starship.python.net
Subject: [Stackless] Re: [Python-Dev] uthread strawman


> Guido:
...
> > Where it gets tricky is when this spawns a new uthread, which also
> > calls C which calls Python... The solution is simply that the 
> > application "shouldn't do that."
> 
> I worry that this is going to be a rather severe restriction.
> For instance, it may make it impossible to spawn a uthread
> from within a callback from a GUI framework. Since with many
> GUI frameworks the entire application gets executed in
> callbacks, you wouldn't be able to use uthreads at all with
> such a framework.

But that's the same problem that current stackless has.  I take it
that you don't see the point of stackless then?  That's fine.  Maybe
this is not an application that could use uthreads.  They seem more
something for servers anyway.

--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Stackless mailing list
Stackless at starship.python.net
http://starship.python.net/mailman/listinfo/stackless
_______________________________________________
Stackless mailing list
Stackless at starship.python.net
http://starship.python.net/mailman/listinfo/stackless