Problems with thread state

[Martin Sjögren]

On Wed, Jul 04, 2001 at 06:01:53PM -0000, Donn Cave wrote:
> Yes, that sounds reasonable to me.  You could continue to use
> BEGIN_ALLOW_THREADS, but the point is that you now have a thread
> state that you can dig up from the callback and use to re-enter
> the interpreter.
> 
> But this is an area of Python internals where I don't have a very
> solid grasp of what I'm doing, so you will have to look at the
> source code and do some of your own analysis.  I see from the
> definition of Py_BEGIN_ALLOW_THREADS that it uses functions that
> are always defined, even when the interpreter was built without
> threads, where the functions I suggested are only present with
> threads so they should be used only if threads are really required.
> 
> You also may need to consider the possibility that two threads
> might concurrently use the same ctx object.

This is what I do now:

#define MY_BEGIN_ALLOW_THREADS(st)    st = PyEval_SaveThread();
#define MY_END_ALLOW_THREADS(st)    { PyEval_RestoreThread(st); \
                                      st = NULL; }

And I enclose the call to SSL_connect with BEGIN and END, and enlose the
call to PyEval_CallObject with END and BEGIN, with a PyThreadState pointer
in my context objects.

It doesn't segfault any more ;)

But you got me thinking. Maybe I ought to do the END/BEGIN thingy not just
around the PyEval_CallObject but right at the start and end of my bogus C
callback. Hmm.

I'm writing this in a "submodule" in socket (from socket import SSL...) so
now socketmodule.c is up to ~110K instead of the ~75K it was before...
ick...

Cheers,
Martin

-- 
Martin Sjögren
  martin at strakt.com              ICQ : 41245059
  Phone: +46 (0)31 405242        Cell: +46 (0)739 169191
  GPG key: http://www.strakt.com/~martin/gpg.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 248 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20010705/9eb0e76e/attachment.sig>