[C++-sig] Managing the GIL across competing threads

[Niall Douglas]

On 16 Mar 2012 at 12:57, Adam Preble wrote:

> Well the current design does have a problem, but I think it's more to do
> with the Python side than the sum of the whole thing.

If by "Python side" you mean Boost.Python, then I agree: BPL has no 
support for GIL management at all, and it really ought to. This was 
one of the things that was discussed in the BPL v3 discussions on 
this list a few months ago.

If by "Python side" you just mean Python, well it's basically one big 
fat lock. There's nothing wrong with that design, indeed it's 
extremely common.

> So I assume I would satisfy your suggestion of a master lock if I basically
> put the interpreter in its own subsystem.  Everybody then gets their turn
> at it.

You need to clarify what you mean by "own subsystem". Do you mean 
"own process"?

> Something I'm curious about has to do with the busy what in my promises and
> future implementation.  When I end up waiting on something, is there a way
> right now with Python to give up the GIL until the wait is done?  If I were
> to do a Release before the wait and an Ensure right after it, will there be
> inconsistent issues?  I ask this despite probably trying it tonight since
> these are the kind of issues that tend to bite me after the fact and not up
> front.

You're going to have to be a lot clearer here. Do you mean you want 
BPL to give up the GIL until the wait is done, or Python?

Regarding inconsistency over releases and locks, that's 101 threading 
theory. Any basic threading programming textbook will tell you how to 
handle such issues.

Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/