search

HEADS-project / heads_ide

http://heads-project.eu
9 stars 2 forks source link

Scheduling of events is different in JS than in Java/C generated code #19

Closed sdalgard closed 9 years ago

sdalgard commented 9 years ago

The PrintIncrementForward made during my training works for Linux C and Plain JAVA. For JS the code runs the first timer tick, but the timer does not reload

brice-morin commented 9 years ago

I indeed reproduced the bug and will investigate further

brice-morin commented 9 years ago

As far as I can tell right now, the problem is not the timer itself. It seems the JS implementation is stuck in the Wait state and does not go back to Init (and does not restart the timer)... I will investigate more...

brice-morin commented 9 years ago

Well... I am still not 100% sure... but it seems unfortunately that the JS behavior is a valid (though unfortunate (and somehow counter intuitive) behavior).

It seems that when the starter sends to_ender!pif_token(1), the chain of incrementer/printers is sending the messages back and forth before the started actually reaches the Wait state.

Again, that is very unfortunate and counter intuitive, but IMHO it seems to be a valid behavior when the different things evolves independently and asynchronously... That kind of synchronization issue would typically appear in a real distributed system. It is just unlucky it happens when everything runs locally...

brice-morin commented 9 years ago

Though it might be possible to seek to yield a more "intuitive" behavior (at least when everything runs locally) using Node.JS process.nextTick in a wise way...

brice-morin commented 9 years ago

Updating the generated code as follows did the trick:

function t2_effect(context, message) {
var json = JSON.parse(message);
console.log("Sender sends token ... \n"); 
process.nextTick(function(){sendPif_tokenOnTo_ender(1);});
}

instead of : 

function t2_effect(context, message) {
var json = JSON.parse(message);
console.log("Sender sends token ... \n");
sendPif_tokenOnTo_ender(1); 
}

I will study the problem a bit more to see if we should generate that kind of code systematically (generating it is easy in itself, but we have to be careful if it is what we always want)