Is Stackless Python DEAD?

[Donn Cave]

Quoth Paul Rubin <phr-n2001d at nightsong.com>:
| Donn Cave <donn at u.washington.edu> writes:
|>    #  callback from UI - selected login option
|>    def login(self):
|>        name = self.config.loginid
|>        password = self.getpassword(name)  # posts password prompt window
|>        #  Function actually returns from callback ...
|>        #  ... New callback arrives with password requested here;  continue!
|>        self.loginwithpassword(name, password)
|> 
|> That's arguably more readable than any alternative I ever thought of,
|> but then it substantially obscures the "real" flow of control in the
|> program.  
|
| Nice!  But really, using callbacks in the first place for things like
| this is a kludge designed to get around the lack of
| coroutines/continuations/threads whatever.  In threaded style you'd
| just write getpassword as an ordinary method call that blocks til
| the password is entered, then returns.

I'm probably missing something here, but note that this system is
built on a multi-threaded context already, and part of the game was
to put the whole system together on a purely I/O dispatched basis.
That message I/O, and the callback dispatching, is a basic given of
the underlying graphics toolkit, and it makes life a lot simpler if
the whole application is on board.

The function is based on something actually do, and I currently use
a version of it that does happen to block for the password.  In this
case, the caller spawns a password prompt interface with a semaphore,
then blocks waiting for the semaphore, then retrieves the password
from a common interlocked data store.  That sounds complicated, but
it's easy to make it work.

But what happens if the password prompt interface isn't a thread that
you can spawn every time you want one, but rather an element inside
a UI thread that;  and that UI thread happens to be asking you for
something that you'll need a password to answer?  You can't ask it
for the password, because it's asking you a question, and blocking
until you come up with an answer.  If all the parties just handle
I/O events and then return without blocking, we don't have that problem,
but in a simple procedural flow of control, the implementation gets
awkward because you have to divide the function into two, the second
one continuing with the password now in hand - and whatever state you
need, which has to be passed on from the first to the second function.
With Stackless' continuations, I could continue right back into the
middle of the function, with the state just where I left off, plus
the password value that came with the present callback.

If this still leaves you thinking that "coroutines/continuations/threads
whatever" would be a more obvious solution, could you elaborate?

	Donn Cave, donn at u.washington.edu