[Swig-user] RE: [Swig-devel] Swig/Python thread support

[Ames A. <And...@co...>]

> -----Original Message-----
> From: Marcelo Matus [mailto:mm...@ac...]=20
> Sent: Wednesday, December 07, 2005 8:22 PM
> To: Ames Andreas
> Cc: swi...@li...; swi...@li...
> Subject: Re: [Swig-user] RE: [Swig-devel] Swig/Python thread support
>=20
> Ok, I remembered the main reason why we can't do this:
>=20
> #      define SWIG_PYTHON_THREAD_BEGIN_BLOCK   {=20
> SWIG_Python_Thread_Block _swig_thread_block
> #      define SWIG_PYTHON_THREAD_END_BLOCK     }
> #      define SWIG_PYTHON_THREAD_BEGIN_ALLOW   {=20
> SWIG_Python_Thread_Allow _swig_thread_allow
> #      define SWIG_PYTHON_THREAD_END_ALLOW     }
>=20
> the code should work in plain C, and we have some gotos=20
> inside there, ie:
>=20
> {
>   SWIG_PYTHON_THREAD_BEGIN_BLOCK;
>   ...
>      if (error) goto fail;
>   ...
>   SWIG_PYTHON_THREAD_END_BLOCK;
>   return resultobj;
> fail:
>   SWIG_PYTHON_THREAD_END_BLOCK;
>   return NULL;
> }

But if SWIG_PYTHON_THREAD_BEGIN_BLOCK is used as (one of) the first =
declarations in the block (before any code that can potentially call =
python code), you don't need SWIG_PYTHON_THREAD_END_BLOCK (in C++ mode) =
anyway, i.e.

#      define SWIG_PYTHON_THREAD_BEGIN_BLOCK   SWIG_Python_Thread_Block =
_swig_thread_block
#      define SWIG_PYTHON_THREAD_END_BLOCK

would be sufficient (and also work, if SWIG_PYTHON_THREAD_END_BLOCK was =
used twice or more). =20

> also, it seems we need to leave the macro
>=20
> #define SWIG_PYTHON_INITIALIZE_THREADS  PyEval_InitThreads()
>=20
> or the test suite fails in many places. If needed, the user can do
>=20
>   c++ -DSWIG_PYTHON_INITIALIZE_THREADS=3D"" ...
>=20
> and that cancels it. Anyway, the docs says it is save to call=20
> PyEval_InitThreads()
> more than once, and if you don't want the swig module to=20
> create the main=20
> thread,
> well you can load the swig module another module creates it, right?.

In which way do the tests fail?  I still think, the side effects of =
PyEval_InitThreads are potentially too dangerous to be acceptable in =
generic code (like swig generated wrappers).  E.g. the docs also state =
(in 8.1):

"It is not safe to call this function when it is unknown which thread =
(if any) currently has the global interpreter lock."

Furthermore in the python sources there is some code which also just =
uses the GILState api without any tests whether the GIL was actually =
created by PyEval_InitThreads (the GIL is actually created, when you =
create a python thread, see Modules/threadmodule.c in the python 2.4 =
source);  examples can be found in Modules/posixmodule.c and =
Modules/readline.c.


cheers,

aa