Moveit stops my other Python threads
94 views
Skip to first unread message
Yoan Mollard
Oct 20, 2014, 9:57:00 AM10/20/14
to moveit-users
Hi moveit users,
I realised that moveit managed somehow to stop my other python threads. I did not even know this was possible.
The enclosed code is an example. A thread performs an infinite loop printing an increasing float. Meanwhile moveit is asked to go to different random targets each second.
You should see the thread being "paused" during go() and being executed only during sleep(1)
What is wrong?
Thanks by advance
Yoan Mollard
Research engineer – 3rd hand project
INRIA Research center, Flowers lab
Wouter van Oijen
Oct 22, 2014, 8:24:01 AM10/22/14
to moveit...@googlegroups.com
Hi Yoan,
It's important to realize that Python does not have "real" multithreading, in the sense that multiple threads can run simultaneously. At any time, there is only one Python thread active, even if you have multiple processors. If you want to know more about that, search for e.g. "Python threading GIL" (GIL = Global Interpreter Lock, which is the reason that only one thread can run and probably the cause of the blocking you've observed in your program). I think the following article gives a good background: http://www.jeffknupp.com/blog/2012/03/31/pythons-hardest-problem/
That being said, I suspect that the Python wrappers for MoveIt! call the C++ library while having the Global Interpreter Lock. That could be intentional (if the library shares data with the Python code), but could also indicate a coding problem. In order to allow other Python threads to be executed during moves, the GIL must be released before entering the MoveIt! library.
Unfortunately I am not familiar with the MoveIt! internals. Maybe someone else can confirm if this is the case, and if this can be improved.
Regards,
Wouter
It's important to realize that Python does not have "real" multithreading, in the sense that multiple threads can run simultaneously. At any time, there is only one Python thread active, even if you have multiple processors. If you want to know more about that, search for e.g. "Python threading GIL" (GIL = Global Interpreter Lock, which is the reason that only one thread can run and probably the cause of the blocking you've observed in your program). I think the following article gives a good background: http://www.jeffknupp.com/blog/2012/03/31/pythons-hardest-problem/
That being said, I suspect that the Python wrappers for MoveIt! call the C++ library while having the Global Interpreter Lock. That could be intentional (if the library shares data with the Python code), but could also indicate a coding problem. In order to allow other Python threads to be executed during moves, the GIL must be released before entering the MoveIt! library.
Unfortunately I am not familiar with the MoveIt! internals. Maybe someone else can confirm if this is the case, and if this can be improved.
Regards,
Wouter
Yoan Mollard
Oct 25, 2014, 3:02:06 PM10/25/14
to Wouter van Oijen, moveit...@googlegroups.com
Hi Wouter,
Hum I see thanks.
As a temporary workaround I don't use threads anymore but nodes instead.
If someone knowing MoveIt internals could have a look to this issue it would be great :)
Cheers
Yoan Mollard
Research engineer – 3rd hand project
INRIA Research center, Flowers lab
Yoan Mollard
Feb 16, 2015, 6:32:47 AM2/16/15
to Wouter van Oijen, moveit...@googlegroups.com
Hi all,
Is there a person familiar with MoveIt internal behaviour to debug this?
I've just opened a ticket on github: https://github.com/ros-planning/moveit_commander/issues/28
Cheers
Yoan Mollard
Research engineer – 3rd hand project
INRIA Research center, Flowers lab
Reply all
Reply to author
Forward
0 new messages