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.

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.

> 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 … :-(

>> 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.

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.

> 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.

That is indeed the price to pay in the suggestion I make. Which choice is
the best will depend on the amount of "side effects" that the external
black box brings in. Or even better: it depends on the _predictability_ of
the "side effects" on the realtime performance: can you have 100%
predictable and satisfiable behaviour of your owm component even when it
will miss some new data from the "black box", or is the latter data more
essential than your own? My suggestion only makes sense in the former case.
(Which I think should be _the_ nominal case: any realtime sub-system must
be able to do the right thing, even when being "abandoned" by its
non-realtime dependencies...

> 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