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/ _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
