Re: (Win32 API) callback to Python, threading hiccups
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.python archive

Re: (Win32 API) callback to Python, threading hiccups

From: Tim Roberts <timr@probo.com>
Date: Fri Jul 08 2005 - 06:40:22 CEST

Scott David Daniels <Scott.Daniels@Acm.Org> wrote:

>Francois De Serres wrote:
>> PyGILState_STATE gil = PyGILState_Ensure();
>> result = PyEval_CallObject(my_callback, arglist);
>> PyGILState_Release(gil);
>> Py_DECREF(arglist);
>> Py_DECREF(result);
>
>I think this should be:
> PyGILState_STATE gil = PyGILState_Ensure();
> result = PyEval_CallObject(my_callback, arglist);
> Py_DECREF(arglist);
> Py_DECREF(result);
> PyGILState_Release(gil);
>
>The DECREFs need to be protected, that is where storage is
>recycled and such, and you still need Python's data structures
>to do that kind of work.

I freely admit to being woefully underinformed about the GIL, but I'm
wondering if your statement is really true. If the purpose of the GIL is
simply to make things thread-safe, then I would have guessed that the first
one was correct. If someone else holds a reference to "arglist", then the
DECREF is just a nice, atomic decrement. If no one else holds a reference
to "arglist", then it's quite safe to delete it.

Is there more to the GIL than I'm assuming?

-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.
Received on Thu Sep 29 16:49:42 2005