Thanks Daniel.
?
Much appreciated that you took the trouble/time to ask on the JMRI developers list.? I can see that Bob has replied, but it looks like I don't have access to answer there. Bob makes a good point about responses not necessarily being received, although the send queue becomes empty. In my specific use case, that is fine though. All I am trying to prevent is more and more messages being added by the NGs, making the send queue longer and longer- the responses coming back later "asynchronously" is fine.?I do agree with Bob's point about possible user confusion though.
?
Thanks for confirming that the single threading is going to work how I expected.
?
I think I might be missing something with your recommendation though. All I am trying to do with the "Execute A after 10 seconds" is make sure that there is time to breathe before the next ConditionalNG kicks into life. I agree that if they were running "all over the place" then it would make sense to use an internal sensor. But here, I am running the ConditionalNGs once when JMRI starts and never again. So, unless I am missing something (which is very likely), I can't see any functional difference between:
?
- Wait ten seconds ....... Return ....... Next Conditional NG starts (because the thread is now free).
- Wait ten seconds ....... Set Internal Sensor ...... Next Conditional NG starts (because the thread is now free) ....... NG checks the sensor, which will always be set by now, and carries on.
Maybe though, good practice says I should use the internal flag approach, just in case the ConditionalNGs are not always only run at startup in the future.
?
Thanks, Nick.
