Understanding PyEval_InitThreads

[hg]

Thomas Heller <theller at python.net> wrote in message news:<lm3nupug.fsf at python.net>...

> There are some drawbacks with this approach as far as I can see: First
> a performance hit, because thread states are frequently created and
> destroyed again.

One way to improve that (especially if you have a lot of threads),
might be to use a cache of thread states. Duncan Grisby's OmniORBpy
does that. Have a look at pyThreadCache.h and pyThreadCache.cc in
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/omniorb/omniORBpy/modules/?only_with_tag=omnipy2_develop

> Second, profiling and setting breakpoints won't work across callouts
> and callins because the profiling and tracing is done with objects
> stored in the thread state itself, and creating a new one doesn't
> inherit them from the saved state. This also affects exceptions, which
> are not propagated back into the 'callout' from the 'callin'.
> 
> Hm, can anyone understand the last sentence?
> What I mean is: When an exception occurs in the callback (which runs
> with a newly created thread state), simply PyErr_Print() is called
> before the thread state is deleted, because there's no way to pass
> the exception somewhere else.

I don't know. Wouldn't PyEval_SetTrace and PyEval_SetProfile help you
out here?

Hans