For more information about this bug, visit
A new bug was added:
Summary: Non periodic+blocking buffered data ports nearly
unusable.
Product: RTT
Version: 1.2.0
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Real-Time Toolkit (RTT)
AssignedTo: orocos-dev [..] ...
ReportedBy: peter [dot] soetens [..] ...

I wanted to write an example of a buffered data port with blocking read
semantics, such that a Pop() on a buffer would block until data was available.
The pop was done in a non periodic activity like this:

void updateHook()
{
// Read buffer port, this is blocking on empty
bool ret = vport.Pop( vel );

// ...process 'vel'

// Inform thread to call updateHook again after this one.
this->engine()->getActivity()->trigger();
}

This program will work as expected when the task is started.
However, when the task is stopped, the application hangs as Pop does not
return, unless you force a value in 'vport'.

These kinds of applications are thus nearly impossible to shut down. The
BufferInterface of Orocos does not provide an 'abort' function to force Pop()
to return (with return value false). Furthermore (but less critical), the
component writer needs to override the stop() function, force the Pop()
operation to abort and then call TaskContext::stop() to pass the stop command
on. This is related to bug #353 . After all, maybe a 'breakLoop()' equivalent
may be required to cleanup these kind of situations

--
(this mail is best viewed with a fixed font)
Configure bugmail: http://www.fmtc.be/orocos-bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm