Problems with thread state

Donn Cave donn at drizzle.com
Wed Jul 4 14:01:53 EDT 2001


Quoth Martin Sjgren <martin at strakt.com>:
...
| But... SSL_connect may call a callback I've set, for verification
| purposes. This function looks somewhat like this:
|
|     // find context and certificate and stuff
|     argv = Py_BuildValue(...);
|     ret = PyEval_CallObject(ctx->verify_callback, argv);
|     Py_DECREF(argv);
|     // handle ret, etc
|
| and this is where it crashes... Should I put in a PyThreadState pointer in
| my ctx objects that I set instead of using BEGIN_ALLOW_THREADS, so I can
| release and re-acquire around the CallObject?

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.

	Donn Cave, donn at drizzle.com



More information about the Python-list mailing list