"Stackless" XEmacs?

[Stephen J. Turnbull]

Jerry James writes:
 > >  It's not obvious to me that this wouldn't be a big win in XEmacs.
 > >  This isn't a realtime OS where you need to discipline badly-behaved
 > >  threads; it's a single-user application where judicious use of
 > >  cooperative multithreading might permit big wins from a few tweaks.
 > 
 > Yes, but we already do that!  That's what the select()/poll() driven
 > event loop is all about: find out what I/O is ready to go, then run
 > the handler to drive it.  There are some places where we don't follow
 > discipline and allow the process to block rather than defer activity
 > to a later iteration of the event loop.  Fixing those would give us
 > the same benefits as this "stackless" architecture.

Well, my understanding is that stackless Python actually exposes those
"threads" to Python.  I don't care how it's implemented, but I really
would like for (a) certain long-blocking applications like Gnus and VM
to more cooperative, and (b) to be able to get information about their
state, maybe, from another thread.

 > Yes, threads are certainly hard.  I'm not necessarily suggesting we
 > dive into using them.  I'm suggesting that the stackless approach is
 > [no panacea].

Oh, of course not.  I'm not pushing the stackless approach per se, I'm
just throwing out ideas.  This one rang my chimes because (a) I have
immense respect for the Python development team and (b) because a 3rd
party brought it up in emacs-devel.

 > I've got too many irons in the fire right now.  Let's postpone this
 > discussion for a few weeks.

I'll assume that's a promise.

These damn Steves (Baur and Yegge, specifically) are giving me an
itch....