I will try and answer this on my iPad, but the usability of this for text entry is horrendous.<br><br>On Tuesday, March 13, 2012, Adam Preble <<a href="mailto:adam.preble@gmail.com">adam.preble@gmail.com</a>> wrote:<br>
> 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.<br>
<br>In this case, with respect to Stackless specifically, you know what Python code is being executed, and you know that unless you're doing some horrendous custom logic within overriding of attribute setting or getting, none of the task lets created on other threads are being invoked.  So setting a Boolean on a python object would be completely safe.  With spect to python and multithreading in general, the Gil makes access to the Boolean safe in the same way as. If you were doing interthread programming with non Stackless pythons.<br>
<br>Note that each Pyhton thread has a scheduler, and task let's created within a thread will be associated with that thread for the purposes of scheduler usage.  It's best to just only create task.ets on the main thread, and use channels or some other form of interfered communication to either communicate with other threads or pass values across.<br>
<br>> 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?<br>> Anyways I think I owe the distribution some code so I'll start pounding away on that in the evening (CST).<br>
<br>Channels are implemented with support for inter thread communication, in addition to their primary purpose of green thread communication.<br><br>Cheers,<br>Richard.