[Stackless] Stackless runtime smacking into GIL while a callback is running
richard.m.tew at gmail.com
Mon Mar 12 22:39:46 CET 2012
I will try and answer this on my iPad, but the usability of this for text
entry is horrendous.
On Tuesday, March 13, 2012, Adam Preble <adam.preble at gmail.com> wrote:
> 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.
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.
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.
> 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?
> Anyways I think I owe the distribution some code so I'll start pounding
away on that in the evening (CST).
Channels are implemented with support for inter thread communication, in
addition to their primary purpose of green thread communication.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Stackless