It's called the Global Interpreter Lock and it's what prevents Python
executed using the standard interpreter from being truly concurrent
(although it also massively simplified efficient interpreter
implementation).
http://docs.python.org/glossary.html#term-global-interpreter-lock
http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock
However, a call to rospy.sleep() should be releasing this lock, and so
shouldn't be locking up the entire interpreter. It depends on how that
sleep call is implemented.
To check if the GIL is the problem, try starting another thread and see
if it keeps executing during the rospy.sleep() call you're having
problems with.
Geoff
On 07/07/10 14:47, Cedric Pradalier wrote:
> On 07/07/2010 12:05 AM, Dan Lazewatsky wrote:
>> I'm writing on a GUI in Python/Tk - I have a subscriber which is
>> listening for image messages and setting a class member variable with
>> the newest image, and a GUI element that needs to use image (after
>> sending a message to move a pan/tilt). On click I use rospy.sleep() to
>> wait for the pan/tilt to settle down before using any images. However,
>> I've noticed that once I call rospy.sleep() inside the click callback,
>> the callback for the image subscriber stops getting called. It was my
>> understanding that subscriber callbacks are run asynchronously in
>> their own thread, so a sleep in a different thread should have no
>> effect. What's going on here? What am I missing?
>>
>> Thanks,
>> -Dan
>> _______________________________________________
>> ros-users mailing list
>> ros-users@code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
> Hi Dan,
>
> Python is sometimes counter-intuitive with his management of threads,
> leading sometimes to some global lock where one thread blocks everything.
> I'd suggest keeping your in-callback time to a minimum, maybe just
> triggering another thread which will do the waiting (or switch to C++,
> with real threads).
>
> HTH
>
(text/plain)