Home Original page

HELP! Obscure Python Reentrancy Question

David Bolen db3l at fitlinxx.com
Mon Feb 25 18:14:41 EST 2002 
Courageous <jkraska at san.rr.com> writes:

> I haven't considered how and when to grab the GIL, and what it
> means from the perspective of two different cooperative threads,
> each of which may (or may not!) be executing a Python code
> fragment, at some partial state of completion. Let me help:

>From later in this thread it looks like you resolved your specific
issue, but just to clarify - in the below:

> def f(task):
> 	do()
> 	some()
> 	task.Step(1)
> 	other()
> 	stuff()
> 	task.Succeed()

it seems reasonable that what's happening is that your scheduler is
controlling the Python execution through your synchronization points,
and the way in which the scheduler "dispatches" one of your bits of
Python code is to return from the Step() function call.

So the only thing that I think is critical is that you ensure that
when the scheduler returns back to the Python function that it holds
the GIL (e.g., grab the GIL before letting the Python call to
task.Step(1) return.  That's assuming that you've ever released the
GIL in your extension - if you haven't, then you're fine too as long
as you ensure only one thread/fiber in the extension lets control go
back to the Python interpreter at one time.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/
More information about the Python-list mailing list