<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>I believe what Richard meant is: if a tasklet has references to resources buried in it's "saved C-stack state" (which of course may go back to where it started)<div>unexpected things may happen as the tasklet executes -- especially if it suddenly finds itself on another thread.</div><div><br></div><div>I don' t think the tasklet *necessarily* references anything troubling -- though clearly there could be bugs...</div><div><div><div><br></div><div>The internals, in the case of multiple threads starting tasklets, are subtle, and not the most tested aspect of Stackless.</div><div><br></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>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>-Jas</div><div><br><div><div>On Mar 12, 2012, at 10:32 AM, Adam Preble wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Mon, Mar 12, 2012 at 12:20 AM, Richard Tew <span dir="ltr"><<a href="mailto:richard.m.tew@gmail.com">richard.m.tew@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, Mar 12, 2012 at 8:28 AM, Adam Preble <<a href="mailto:adam.preble@gmail.com">adam.preble@gmail.com</a>> wrote:<br>
> I'm assuming that somehow Stackless didn't get the memo that I stole the<br>
> interpreter for a moment for another thread.  Is there some special rules I<br>
> need to honor with it when I do this crazy stuff?<br>
<br>
</div>The one key thing with respect to Stackless to keep in mind, is that<br>
tasklets may be composed out of parts of the thread they were created<br>
on.  This means that if you try and run them on another thread.. I'm<br>
not sure what happens.  Is it possible that is your problem?  I find<br>
it a little hard to get a grasp on what you are doing, and exactly<br>
what problem arises from reading your email unfortunately.<br>
<div class="im"><br></div></blockquote><div>I suppose we should get into the programming legalese of "may be composed." Is that "must?" I am basically doing what you're pondering I'm doing.  The declaration of the class happens in the bringup code of the thread that starts Python and has the Python interpreter.  The callback arrives from a thread in the C++ runtime.  I suppose since it's enough of a mystery problem, I can try to doodle something up that's easier to show on pastebin or something.  </div>
<div><br></div><div>I would be dismayed if this were the problem.  From what I could tell, if I acquired the GIL in conventional Python, then I was in the clear.  What would be my alternative then for Stackless?</div><div>
 </div></div>
_______________________________________________<br>Stackless mailing list<br><a href="mailto:Stackless@stackless.com">Stackless@stackless.com</a><br>http://www.stackless.com/mailman/listinfo/stackless</blockquote></div><br></div></div></div></body></html>