[Stackless] [Micro-Threads] Reliably retrieving the current exception for thecurrent micro-thread
tismer at tismer.com
Fri Nov 10 23:25:46 CET 2000
you've put your finger into a painful area :-)
Mike Fletcher wrote:
> Unfortunately, under micro-threads, the except clause using
> traceback.print_exc winds up reporting the last exception that occurred in
> _any_ micro-thread (including those which have been successfully caught and
> handled in other micro-threads). Since I have nonblocking socket I/O
> running (which uses socket.error exceptions to indicate blocking), I tend to
> get the socket error returned (which is entirely unhelpful), instead of the
> informative exception for which I'm looking.
Well, exception handling in Stackless is a bit rudimentary
at the moment. Basically, they are not uthread-aware.
There are still the per-thread traceback variables used.
uThreads don't record exceptions by themselves.
They just block in the presence of an exception, therefore
make the system single-uthreaded, and hope that the user
does his exception handling in this context.
Simply put: You cannot rely on exceptions outside of the
exception handler of an uThread, now.
Positively put: Inside an exception handler of an uThread,
you can rely on exceptions.
That means: Either you handle all of your exceptions properly
in place, or we have to design how uThread exceptions *really*
should work. Ahem :-)
Question 1: Should we try to solve this, while uThreads still
are based upon continations and lots of Python overhead?
Or should this be solved when we rewrite the basic stuff
differently, in C?
Question 2: Should uThreads try to mimick the default system
behavior, like it is done with real threads currently?
Or should we keep the current behavior, and provide an
additional method that retrieves the right exception for
a specific uThread?
Question 3: Currently, I'm blocking on exceptions, mainly
because I can't stand a context switch in the middle of
an excpetion. Given that we maintain exceptions per uThread,
shoud we then still block, for simplicity, or not?
Question 4,5,6,7,...: What do you consider more urgent: Fixing
exception handling, or moving Stackless to Python 2.0?
Should I continue to hack on the current patch set, or
is this the time to do a major redesign of stackless? Do
we continue to support continuations, or do we decline to
coroutines, as Guido suggested?
I got some time to work on Stackless again, since a very
kind company on this list decided to pay me some sponsorship!
This is absolutely great, but now I have to decide how
to waste this resource the most efficient way :)
Hey_all__quo_vadis_stackless_python_? - ly y'rs - chris
p.s.: I'm trying to finally switch the python.net domain
over to Digital Creations right now -- it may be better
to stop using this list for one or two days.
Christian Tismer :^) <mailto:tismer at tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Kaunstr. 26 : *Starship* http://starship.python.net
14163 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
where do you want to jump today? http://www.stackless.com
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless