Emission handling when using monitors

[goldhoorn]

I dont't want to continue the discussion on stackexchange. I uploaded the logfile to:

http://auv.informatik.uni-bremen.de/framework/logs/syskit-event-submission-bug/avalon-events.log

The error is between cycle 3457 and 3610, in 3457 the PipelineDetector goes from stop to success, in the next cycle it emits a weak_signal. I assume the problem is a race-problem. Syskit needs to long for the reconfiguration of the network, the task therefore is not stopped and changes his state.
In the meantime syskit assumes that the task is stopped and can't handle the event submission anymore.

But in general what i wonder, the task should not be stopped, because it is needed in the later setup also. The next state of the state-machine should reuse it.. but i think this should be resolved by the graph-merging in later steps that could not archived caused by the error.

[doudou]

Hey. Please add screenshots of the steps you are talking about in the
issue, thanks.

2014-07-01 11:32 GMT+02:00 Matthias Goldhoorn [email protected]:

I dont't want to continue the discussion on stackexchange. I uploaded the
logfile to:

http://auv.informatik.uni-bremen.de/framework/logs/syskit-event-submission-bug/avalon-events.log

The error is between cycle 3457 and 3610, in 3457 the PipelineDetector
goes from stop to success, in the next cycle it emits a weak_signal. I
assume the problem is a race-problem. Syskit needs to long for the
reconfiguration of the network, the task therefore is not stopped and
changes his state.
In the meantime syskit assumes that the task is stopped and can't handle
the event submission anymore.

But in general what i wonder, the task should not be stopped, because it
is needed in the later setup also. The next state of the state-machine
should reuse it.. but i think this should be resolved by the graph-merging
in later steps that could not archived caused by the error.

—
Reply to this email directly or view it on GitHub
#3.

[goldhoorn]

Here they are

3457:

3610:

[doudou]

I assume that the one at the top is 3610 and the one at the bottom 3457...
Would have been nice to have them in chronological order ...

[goldhoorn]

Sorry, yep, the information was not displayed default, i added the info above. By "editing" the message you would have seen the names...

[doudou]

FYI, there's a nice preview mode to make sure that you did not get the
markdown wrong

2014-07-02 9:41 GMT+02:00 Matthias Goldhoorn [email protected]:

Sorry, yep, the information was not displayed default, i added the info
above. By "editing" the message you would have seen the names...

—
Reply to this email directly or view it on GitHub
#3 (comment).

[doudou]

OK ... so.

It is what I thought. Not a race condition, syskit/roby do what they are supposed to do here. It is just that the task emits the weak_signal event, which gets forwarded to the compositions that are not yet running. There are number of reasons why, in this situation, the compositions would not be running (e.g. having a temporal constraint forbidding them to be), so everything in the code behaves as it is supposed to.

Which brings me to the real problem. Theoretically, the forwarding relation should not be setup until the target task is started in this case. However, this is roby-theoretical-from-2007 before syskit started existing and I am now thinking that it should not be the case. IMO, the right fix would be that the forwarding relation should simply be ignored if the target task is not started.

[goldhoorn]

Could you propose a pull-request which i can try?

[doudou]

Nope, because I don't have the time. Feel free to do it, though.

2014-07-04 10:14 GMT+02:00 Matthias Goldhoorn [email protected]:

Could you propose a pull-request which i can try?

—
Reply to this email directly or view it on GitHub
#3 (comment).

[goldhoorn]

Could you give a hit instead for the right solution instead simply removing the error message?

[doudou]

???

[goldhoorn]

Whats unclear?

I want a hint for the right fix if possible.
So that i can provide a correct fix.

Br

Von meinem iPhone gesendet

Am 08.08.2014 um 19:30 schrieb Sylvain Joyeux [email protected]:

???

—
Reply to this email directly or view it on GitHub.

[doudou]

Ah ... now it's clear ;-)

As I mentioned in #7, that would require a level of knowledge of Roby's internals that you really don't have... And I have little time to explain it. I am testing different ways to do it, but that's going to take some time. If the original fix works for you, stick to it for now.