[Python-Dev] Replacing threads with swapcontext()

Alexander Sabourenkov screwdriver at lxnt.info
Thu Apr 1 11:49:43 CEST 2010


Nick Coghlan wrote:
> Off the top of my head, recursion limit checks will definitely go
> haywire, and I would expect threading.local() and exception handling to
> explode at some point (although the latter depends on what you mean by
> "switching C stacks" - if you really are just fiddling the stack pointer
> without affecting the thread local heap storage mechanisms, the latter
> two should be fine. Still doesn't sound like a good idea though).

In my implementation, each context looks like a thread to Python, with 
its own PyThreadState, thread-local storage and locks are taken care of,
so I'm reasonably sure there's nothing scary lurking unseen.

I'm trying to confirm my understanding as to how unreliable the greenlet 
is. The greenlet module basically just switches C stacks and does not 
touch anything else. There evidently are problems with this when there's 
an exception raised, as it's stored in PyThreadState::curexc_*/exc_*.

PyThreadState's profiling/tracing -related members, the tick_counter, 
and per-thread state dict don't appear as a problem at the first glance.

recursion_depth will be messed up unpredictably, as you kindly pointed out.

This leaves PyThreadState::frame a PyFrameObject to be examined.

Do they form a python-side stack of a thread in question?

-- 

./lxnt






More information about the Python-Dev mailing list