[Stackless] Ideas for Uses of Stackless Python

Mike C. Fletcher mcfletch at home.com
Sat Jun 9 15:50:51 CEST 2001


I've done something similar.  I allowed standard RPC mechanisms intermixed
with asynchronous send/receive mechanisms (as a note, I also had timeouts on
all network calls, I never observed a deadlock state).  I built a framework
such that you could call across the network, choosing whether to block the
current micro-thread or not, and whether to pass an asynchronous callback or
not.  Micro-threading was fairly critical to the project as you wound up
with hundreds of suspended calls chaining across the various machines in the
system.  With it, you can right fairly straightforward looking code (as
compared with the IMO rather nonintuitively structured E code samples), as
you can use the micro-thread's state for almost everything.  If an exception
occurs, you just raise the exception in the suspended micro-thread, if it
doesn't, you return the value.  Callbacks work as normal.  The idea of
adding an explicit "promise" as well as "proxy" objects has some attraction.

Not sure if E actually does it, but it might be interesting to see if you
could generate a system capable of sending the messages to the proxy's
target before the proxy has resolved to an object (in essence, you would
want to be able to send all messages which do not branch on the results of
an unknown network query, with a tree structure being maintained such that
any given new result will cause all dependent queries to be immediately
sent), which would be no more than a matter of using a speculative target ID
in the messages, but it's something I didn't do in my system.  Strangely,
however, as I look at the description, that's what the system I built does
at some level of abstraction, with the tree structure being a set of
suspended micro-threads which are un-blocked when the results come in... oh
well.

Unfortunately, that system was done for a closed-source company, so it is
not available anymore :( .

Incidentally, most of the complexity in the project was around the security
system (of which E has no appreciable one that I can see, relying instead on
some silly obfuscation mechanism), and the code to make the messaging
lightweight (this was for a distributed virtual reality system, so bandwidth
constraints were considerable) and objects cleanly persistent .

Enjoy yourselves,
Mike

-----Original Message-----
From: stackless-admin at starship.python.net
[mailto:stackless-admin at starship.python.net]On Behalf Of Kevin
Littlejohn
Sent: June 9, 2001 06:14
To: Jeff Rush
Cc: stackless at starship.python.net
Subject: Re: [Stackless] Ideas for Uses of Stackless Python



If anyone were to be looking into this, I'd love to hear about it - I've
been
for a long time tinkering with a distributed object thing in python, that's
shortly going to shift to microthreads, and will probably have to implement
something akin to E's promises to deal with distributed coding.

KevinL

>>> Jeff Rush wrote
> Are you aware of the E Language, located at
>
>     http://www.erights.org
>
> I've been following it for a few months and I think we could steal
> some neat features and use microthreads to implement them.
>
> In particular, something like the Eventually operator and
> Promises, described at:
>
>     http://www.skyhunter.com/marcs/ewalnut.html#SEC19
>
> I took a look at Willis' microthread API.  It looks similar
> to the one for the Thread/Threading module.  I'm hoping for
> something a bit different and easier to use than traditional
> multithreading, like Promises, which can never deadlock.  The
> Promises concept spins off microthreads transparently.
>
> -Jeff

_______________________________________________
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



More information about the Stackless mailing list