[Stackless] [Micro-Threads] Reliably retrieving the current exception for thecurrent micro-thread

[Mike Fletcher]

Q1 -- No, not immediately necessary, a better long-term solution is what's
wanted.
Q2 -- I'd prefer that exceptions operate in a manner which is exactly like
normal Python code, that is, just like in a normal threaded interpreter.
Having to explicitly code threading-aware stuff into your app is a pain.
Q3 -- Doesn't appear to block now, so I probably don't understand the
question.
Q4 -- I'd put a 2.0 move as first priority still.  Exception handling isn't
a huge issue for me.  Oh, I _am_ handling these exceptions in the except
block within the uthread, so I'm not really sure what you mean when you say
stackless does block on an exception.
Q567 -- Redesign it, with input from Guido and the rest, for Python 2.0.
How does Guido's proposal handle timeslicing/scheduling?  It seems to be
predicated on each "thread" explicitly yielding control, rather than a
pre-emptive system (not very useful IMO, means you have to explicitly code
thread control all through your app).  Did I miss something about it?

Enjoy yourself,
Mike

-----Original Message-----
From: Christian Tismer [mailto:tismer at tismer.com]
Sent: Friday, November 10, 2000 5:26 PM
To: Mike Fletcher
Cc: 'Stackless Python (E-mail)'
Subject: Re: [Stackless] [Micro-Threads] Reliably retrieving the current
exception for thecurrent micro-thread
...
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.
...
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?
...