Hi all,

On 27/11/15 08:05, Herman Bruyninckx wrote:
> On Thu, 26 Nov 2015, S Roderick wrote:
>
>>> On Nov 25, 2015, at 10:18, Sergio Portoles
>>> <Sergio [dot] PortolesDiez [..] ...> wrote:
>>>
>>> Dear orocos users,
>>>
>>> We are programming a component that communicates with a device
>>> (robot). This communication is done through an API that is provided
>>> by the vendor and the library behind is pretty much closed.
>>>
>>> They way of using it is as follows:
>>>
>>> typedef void* DeviceHandle // So no information about their structure
>>> that we can check
>>>
>>> int main() {
>>> DeviceHandle m_device;
>>> if ( NULL == m_device = API_openDevice( "192.1..." ) ) return;
>>> API_configureDevice(m_device, opts);
>>> }
>>>
>>> When calling API_openDevice(...), the library seems to create two
>>> threads, according to gdb and probably allocating some memory.
>>>
>>> The problem is that, if we place this simple piece of code inside a
>>> component we risk to get a segmentation fault during the call to
>>> API_configureDevice().
>>> Note that, when it fails the pointer returned by API_openDevice() is
>>> not NULL or 0x0, but something else, probably with some corrupted
>>> data, cannot really know.
>>>
>>> * When it happens:
>>> Our inquiries tell that, if you place the code on the configureHook
>>> and the configure function of the component is called by the
>>> deployer, during the deploy execution, it works fine. Instead, if you
>>> let another component call the configure, i.e. a Supervisor
>>> component, it will fail.
>>> If we put the code in an operation run by RTT::ClientThread will only
>>> success when is called from deployer but not when called from a
>>> different component. If the operation is set to by executed in
>>> RTT::OwnTrhead, it will always fail.
>>>
>>> * System used:
>>> Ubuntu 12.04 + PREEMTED rt patch kernel
>>> Orocos 2.6 installed from packages (.deb)
>>> ROS groovy installed from packages (.deb)
>>>
>>> So the question, I wonder if any component different to the deployer
>>> finds a limit on the resources that can allocate or any other limit
>>> regarding creating new threads or the such. So that, only the
>>> deployer thread can make this piece of code work. This is the main
>>> difference that I can think of.
>>>
>>> Bests,
>>> Sergio
>>
>> The deployer runs in the main thread, and is the item that calls
>> configureHook() on all components that are
>> auto-configured/auto-started (IIRC). So it sounds like the library is
>> sensitive to being called from a thread *other than* the main thread.
>> Shrug … given that it’s a black box, you might not have many options …
>> :-(
>
> In my opinion, a sensitive approach here is to put the black box in
> its own process (not thread...) and mediate an IPC between that process'
> sub-system and your Orocos sub-system.
>

Indeed, that seems to be a much cleaner way. Only practical problem is
adding another layer of communication between the control part and the
actual hardware.

Sergio

>> HTH
>> Stephen
>
> Herman

2015-11-27 8:05 GMT+01:00 Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...>:

> On Thu, 26 Nov 2015, S Roderick wrote:
>
> On Nov 25, 2015, at 10:18, Sergio Portoles <
>>> Sergio [dot] PortolesDiez [..] ...> wrote:
>>>
>>> Dear orocos users,
>>>
>>> We are programming a component that communicates with a device (robot).
>>> This communication is done through an API that is provided by the vendor
>>> and the library behind is pretty much closed.
>>>
>>> They way of using it is as follows:
>>>
>>> typedef void* DeviceHandle // So no information about their structure
>>> that we can check
>>>
>>> int main() {
>>> DeviceHandle m_device;
>>> if ( NULL == m_device = API_openDevice( "192.1..." ) ) return;
>>> API_configureDevice(m_device, opts);
>>> }
>>>
>>> When calling API_openDevice(...), the library seems to create two
>>> threads, according to gdb and probably allocating some memory.
>>>
>>> The problem is that, if we place this simple piece of code inside a
>>> component we risk to get a segmentation fault during the call to
>>> API_configureDevice().
>>> Note that, when it fails the pointer returned by API_openDevice() is not
>>> NULL or 0x0, but something else, probably with some corrupted data, cannot
>>> really know.
>>>
>>> * When it happens:
>>> Our inquiries tell that, if you place the code on the configureHook and
>>> the configure function of the component is called by the deployer, during
>>> the deploy execution, it works fine. Instead, if you let another component
>>> call the configure, i.e. a Supervisor component, it will fail.
>>> If we put the code in an operation run by RTT::ClientThread will only
>>> success when is called from deployer but not when called from a different
>>> component. If the operation is set to by executed in RTT::OwnTrhead, it
>>> will always fail.
>>>
>>> * System used:
>>> Ubuntu 12.04 + PREEMTED rt patch kernel
>>> Orocos 2.6 installed from packages (.deb)
>>> ROS groovy installed from packages (.deb)
>>>
>>> So the question, I wonder if any component different to the deployer
>>> finds a limit on the resources that can allocate or any other limit
>>> regarding creating new threads or the such. So that, only the deployer
>>> thread can make this piece of code work. This is the main difference that I
>>> can think of.
>>>
>>> Bests,
>>> Sergio
>>>
>>
>> The deployer runs in the main thread, and is the item that calls
>> configureHook() on all components that are auto-configured/auto-started
>> (IIRC). So it sounds like the library is sensitive to being called from a
>> thread *other than* the main thread. Shrug … given that it’s a black box,
>> you might not have many options … :-(
>>
>
> In my opinion, a sensitive approach here is to put the black box in
> its own process (not thread...) and mediate an IPC between that process'
> sub-system and your Orocos sub-system.
>
>
+1

> HTH
>> Stephen
>>
>
> Herman
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>