[Bug 886] New: Same port names: EventPort in A causes Port in B to wake up

http://bugs.orocos.org/show_bug.cgi?id=886

Summary: Same port names: EventPort in A causes Port in B to
wake up
Product: Toolchain
Version: master
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: RTT
AssignedTo: orocos-dev [..] ...
ReportedBy: steven [dot] bellens [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

I'm not sure whether you guys will consider this as a bug or not, but it's
definitely unexpected behaviour from my side, so I file it here :).

Use case:

Consider 3 components (A,B,C) which act in an event-driven system:

Component A: wakes up due to an external program, calculates some stuff and
writes the result to its output port 'output_A'

Component B: has an event input port which gets triggered by 'output_A',
calculates some stuff and writes the result to its output port 'output_B'

Component C: has an event input port which gets triggered by 'output_B',
calculates some stuff and writes out.
_BUT_, C, also needs 'output_A' to do its calculations. However it should _not_
be triggered by that port. So both B and C are connected to 'output_A', but in
B its an EventPort, and in C its a normal Port.

Problem:

as both B and C subscribe to 'output_A', it makes sense to give the
(Event)Input ports the same name (in the TaskBrowser). However, this same name
will cause C to wake up by that port as well!

[Bug 886] Plain ports wake up the TC

http://bugs.orocos.org/show_bug.cgi?id=886

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Target Milestone|--- |next-major

--- Comment #6 from Peter Soetens <peter [..] ...> 2011-08-24 00:16:53 CEST ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Created attachment 720 [details] [details] [details]
> > > Patch with _partial_ solution
> >
> >
> > Currently, plain ports get triggered as well. This fix solves the bug
> > _partially_. Plain ports don't get triggered anymore, eventports get triggered,
> > _if_ they have a custom callback method assigned (boost::bind(...)). So the
> > default event port which triggers updateHook is not triggered now. Solve this
> > by updating the callback default value to point to updateHook()?
>
> No that will cause updateHook to be called twice. I think there's no other way
> than using a flag in the port or in the connection endpoint which decides on
> waking up the TC.

I fixed it this way and pushed to master. Unit test confirms fix.

Peter

[Bug 886] Plain ports wake up the TC

http://bugs.orocos.org/show_bug.cgi?id=886

--- Comment #5 from Peter Soetens <peter [..] ...> 2011-07-31 11:58:38 CEST ---
(In reply to comment #4)
> (In reply to comment #3)
> > Created attachment 720 [details] [details]
> > Patch with _partial_ solution
>
>
> Currently, plain ports get triggered as well. This fix solves the bug
> _partially_. Plain ports don't get triggered anymore, eventports get triggered,
> _if_ they have a custom callback method assigned (boost::bind(...)). So the
> default event port which triggers updateHook is not triggered now. Solve this
> by updating the callback default value to point to updateHook()?

No that will cause updateHook to be called twice. I think there's no other way
than using a flag in the port or in the connection endpoint which decides on
waking up the TC.

Peter

[Bug 886] Plain ports wake up the TC

http://bugs.orocos.org/show_bug.cgi?id=886

--- Comment #4 from Steven Bellens <steven [dot] bellens [..] ...> 2011-07-29 16:30:13 CEST ---
(In reply to comment #3)
> Created attachment 720 [details]
> Patch with _partial_ solution

Currently, plain ports get triggered as well. This fix solves the bug
_partially_. Plain ports don't get triggered anymore, eventports get triggered,
_if_ they have a custom callback method assigned (boost::bind(...)). So the
default event port which triggers updateHook is not triggered now. Solve this
by updating the callback default value to point to updateHook()?

[Bug 886] Plain ports wake up the TC

http://bugs.orocos.org/show_bug.cgi?id=886

--- Comment #3 from Steven Bellens <steven [dot] bellens [..] ...> 2011-07-29 16:28:59 CEST ---
Created attachment 720
--> http://bugs.orocos.org/attachment.cgi?id=720
Patch with _partial_ solution

[Bug 886] Same port names: EventPort in A causes Port in B to wa

http://bugs.orocos.org/show_bug.cgi?id=886

--- Comment #2 from Steven Bellens <steven [dot] bellens [..] ...> 2011-07-29 08:41:57 CEST ---
(In reply to comment #1)
[...]
>
> The name of the port is nowhere used in Orocos (except the deployer uses it for
> lookup when forming a connection).
>
> So you're seeing something else. A 'plain' port can never wake up the
> taskcontext. Unless a bug slipped into the event port refactoring on master,
> and that on the master branch 'plain' ports wakeup the TC as well:

Yes, indeed, testing a bit more reveals it: 'plain' ports wakeup the TC on the
master branch ...

Steven

>
> Peter

[Bug 886] Same port names: EventPort in A causes Port in B to wa

http://bugs.orocos.org/show_bug.cgi?id=886

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |peter [..] ...

--- Comment #1 from Peter Soetens <peter [..] ...> 2011-07-28 22:40:29 CEST ---
(In reply to comment #0)
> I'm not sure whether you guys will consider this as a bug or not, but it's
> definitely unexpected behaviour from my side, so I file it here :).
>
> Use case:
>
> Consider 3 components (A,B,C) which act in an event-driven system:
>
> Component A: wakes up due to an external program, calculates some stuff and
> writes the result to its output port 'output_A'
>
> Component B: has an event input port which gets triggered by 'output_A',
> calculates some stuff and writes the result to its output port 'output_B'
>
> Component C: has an event input port which gets triggered by 'output_B',
> calculates some stuff and writes out.
> _BUT_, C, also needs 'output_A' to do its calculations. However it should _not_
> be triggered by that port. So both B and C are connected to 'output_A', but in
> B its an EventPort, and in C its a normal Port.
>
> Problem:
>
> as both B and C subscribe to 'output_A', it makes sense to give the
> (Event)Input ports the same name (in the TaskBrowser). However, this same name
> will cause C to wake up by that port as well!

The name of the port is nowhere used in Orocos (except the deployer uses it for
lookup when forming a connection).

So you're seeing something else. A 'plain' port can never wake up the
taskcontext. Unless a bug slipped into the event port refactoring on master,
and that on the master branch 'plain' ports wakeup the TC as well:

Peter