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. Most of my threads are basically subsystems in their own rights, and whatever that subsystem manage is encapsulated inside it. I get into this little spats when I need to request a resource from one or more of them--not necessarily from one subsystem to another, just in my main script I have to create an object that involves a piece from one and a piece from another. The subsystems will normally get to them when they are not in their own critical sections. I just got bit when they both went through what is essentially an unprotected interpreter.
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. 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. On Fri, Mar 16, 2012 at 10:38 AM, Niall Douglas <s_sourcefo...@nedprod.com>wrote: > The key to avoiding deadlocks is, in every case, the appropriate > design. > > In what you posted you appear to be doing too much at once, so you're > holding onto too many locks at once. Either replace those with a > single, master lock or try to never hold more than one lock at any > one time. That includes the GIL. In well designed code, one almost > NEVER holds more than two locks at any time. > > Consider breaking object instantiation up into well defined stages. > Consider throwing away your current implementation entirely and > starting from scratch. Debugging a bad design will take longer and > cost more than throwing it away and starting again with the benefit > of hindsight. > > Niall > > >
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
