<br><div class="gmail_quote">On Mon, Mar 12, 2012 at 10:00 AM, Jeff Senn <span dir="ltr"><<a href="mailto:senn@maya.com">senn@maya.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br></div><div><div><div>That said: those of us who have tried to work around possible bugs have found some success in limiting the exposure</div><div>of the tasklet mechanism to multithreading by keeping tasklet creation and execution confined in a particular thread.</div>
<div>e.g. you might create a thread-safe queue of python objects representing "potential" tasklets that a single thread is then popping to </div><div>create and execute the *actual* tasklets.  Even if this is not a perfect solution for you, it may lead to finding race-conditions</div>
<div>or reference errors in the code on the boundary of C++ and Python...</div><div><br></div></div></div></div></blockquote><div>Is this queue itself in Python or C++?  I wasn't clear on that and I can imagine that would matter a little bit.  </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div></div><div>I, also, could not tell what exactly you were doing from your email...so I'm not sure whether this is a helpful suggestion or not.</div>
<div><br></div></div></div></div></blockquote><div><br></div><div>I'm going to try some stuff tonight, and perhaps start trying to type up an example so everybody has something to munge on.  It's non-trivial though so it's not the kind of thing I can just slap together real quick, so that's why I started with a rambly email.  Of particular note in the code I wrote was that I wasn't really taking advantage of Stackless Python in it (yet).  </div>
<div><br></div><div>Anyways I had a thought about what might be wrong, but I'm not sure what I can do about it.  Let's say when one of my C++ threads does the callback, I'm toggling a boolean value in a Python object.  That Python object was created prior in the original Python thread.  In that original thread, it is basically spinning in a loop on that bool.  When the foreign thread touches the bool, do I invite myself to trouble?  I can get away with horrors like that in C++ since bools are just value types and cross-core cache coherency protocols will get the memo across eventually; but I wonder in PythonLand--where everything is a reference--if that is a smart thing to try to do.  I was assuming that by grabbing the GIL I was in control but maybe that's not safe.  Or perhaps worse still in the Stackless context switch stuff, the bool would get mashed up.</div>
<div><br></div><div>So I wonder, if I used a channel instead would that be a safe resource for communicating across two literal threads, versus just two green threads?</div><div><br></div><div>Anyways I think I owe the distribution some code so I'll start pounding away on that in the evening (CST).</div>
</div>