Stackless/microthreads merge news

Donn Cave donn at u.washington.edu
Wed May 17 13:54:16 EDT 2000


Quoth Jeff Senn <senn at maya.com>:
| Hm -- I've been trying to find a way to explain the "stackless zen".
|
| It seems that we all (people who write high level software) take the
| program stack, as a method of flow control and messaging between
| function invocation, as a given.  Really the stack is just another
| data/object type -- not any more special than a queue or a heap...
|
| Given our usually math notation, methods of functional composition and
| early compiler/OS development I'm not surprised that the stack is
| viewed so.  (Consider as a counter example how asynchronous circuit
| design is done and microcode is developed)
|
| IMHO this dependence on making the stack of higher importance has made
| the implementation of multi-"threaded" operating systems complex and
| limited the ways in which alternative approaches could reduce the
| difficulty of implementation of async/parallel systems.
|
| Anyway I hope this stimulates some thought...

It's certainly stimulates some desire for thought.  I have problems
with flow control in asynchronous parallel threaded systems, where
hierarchical function call/return flow of control is replaced by I/O
("messages") between threads.  I use Python because I'm not smart
enough for C++, though, so can I try to pose a more tangible example?

Suppose my interface thread tells a service thread to do its thing,
and report back. That's in function UserX line 135.  It then goes on
to process whatever other interface events may occur.  The service
thread does its thing, and reports back.  Now among the interface
events, there's an event from the service thread that reports the
results from the request at UserX line 135, and I have to figure
out which data item I was looking at, etc., basically the state of
the program at UserX line 135 that time.

Normally, I'd cope with this with some ad hoc state data, maybe
stored by the interface thread, or passed to the service thread who
is expected to pass it back, or some combination of these two.

I sort of get that with this stackless system, I'd have some way
to suspend after UserX line 135 that time, and continue from the
receipt of that event.  So maybe I'd pass the service thread a
unique key to my interface thread suspended-functions space, and
use the key when I get it back in a message?  That continuation
is invoked from the message processing loop, which probably also
originally called the function in the first place;  the original
call must have returned immediately from the suspend, and the
second returns from the continuation?

This still looks at the program in terms of call and return, though,
right?  It only accommodates asynchrony within that relationship.
If instead of wanting to pick up from UserX line 135, my program
often needs to communicate results from one service thread call to
_several_ interface threads, then I'm going to have to write off
"return" and work on the program in terms of state data, and stackful
or stackless makes no difference.  Which I admit can get pretty
gnarly, at least in my limited experience.

	Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list