{"action":"closed","issue":{"url":"https://api.github.com/repos/timpokorny/wantest/issues/5","labels_url":"https://api.github.com/repos/timpokorny/wantest/issues/5/labels{/name}","comments_url":"https://api.github.com/repos/timpokorny/wantest/issues/5/comments","events_url":"https://api.github.com/repos/timpokorny/wantest/issues/5/events","html_url":"https://github.com/timpokorny/wantest/issues/5","id":54696453,"number":5,"title":"Port federate code to use the immediate callback facilities rather than evoked","user":{"login":"timpokorny","id":912209,"avatar_url":"https://avatars.githubusercontent.com/u/912209?v=3","gravatar_id":"","url":"https://api.github.com/users/timpokorny","html_url":"https://github.com/timpokorny","followers_url":"https://api.github.com/users/timpokorny/followers","following_url":"https://api.github.com/users/timpokorny/following{/other_user}","gists_url":"https://api.github.com/users/timpokorny/gists{/gist_id}","starred_url":"https://api.github.com/users/timpokorny/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/timpokorny/subscriptions","organizations_url":"https://api.github.com/users/timpokorny/orgs","repos_url":"https://api.github.com/users/timpokorny/repos","events_url":"https://api.github.com/users/timpokorny/events{/privacy}","received_events_url":"https://api.github.com/users/timpokorny/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/timpokorny/wantest/labels/new%20feature","name":"new feature","color":"84b6eb"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-01-18T13:27:46Z","updated_at":"2015-01-28T12:08:25Z","closed_at":"2015-01-28T12:08:25Z","body":"Story\r\n----\r\n**{As a}** developer of an open source RTI,\r\n**{I want}** my benchmarking suite to run as fast as humanly possible,\r\n**{So that}** I can test the limits of the RTI, not the benchmarking application\r\n  \r\nContext\r\n----\r\nThe HLA defines a series of asynchronous services. In 1516e federates can control the way that they receive callbacks. Previously, you had to call `tick()` or `evokeXxxCallbacks()` to signal to the RTI when you were ready to process waiting messages. As of 1516e you can enable an \"immediate\" callback mode, which essentially delivers callbacks as soon as they are ready (done on a separate thread).\r\n\r\nPart of the problem with the `tick()` style services is that you have very little control over how long you tie up the process for. The provided facilities in 1516e are:\r\n\r\n  * `evokeCallback( double minWaitTime )` - Process a single callback, waiting for the specified given time at a minimum if there are no messages to process\r\n  * `evokeMultipleCallbacks( double mintime, double maxtime )` - Process many callbacks, waiting for at least `mintime` but no longer than `maxtime`\r\n\r\nThe issue here is that when calling these methods I may block if there is no work to do, and I have to wait at least `mintime` for something to appear. This is time I could be using to do other work. In many circumstances this may not be important, but when you're working on a application that you want to push out information as fast as possible, the use of these services introduces an arbitrary delay. Playing with the `loop-wait` argument that the test federate takes lets you see this in action. The higher the value, the slower the throughput.\r\n\r\nWhy not just blat everything out and not tick until the end!? No - idiot - you'll fill up your queue with messages from other federates and run out of memory. The queues inside an LRC need tending, and the `tick()/evoke()` calls as the formal handing over of power to the LRC to do them. Also, it's not really indicative of \"real world\" use.\r\n\r\nSo, what would be better is to use the immediate callback facilities that are available. In Portico - and I suspect every other RTI - this basically means that a background thread is running constantly, tending to the incoming messages and invoking calls on the `FederateAmbassador`. You no longer need to call the tick/evoke methods, and nor do you need to worry about handing over time to queue-tend to ensure it doesn't grow to big. It's just done for you.\r\n\r\nRamifications? You can get `FederateAmbassador` calls at any time - including when you're right in the middle of doing other work, so be careful about any shared state.\r\n\r\nIt would be nice as part of this ticket to maintain the ability to use evoked callbacks if a particular command line argument was given. This would let us contract performance under each style.\r\n\r\nThus ends this completely unnecessary and lengthy commentary on a ticket that could have read \"move from evoked to immediate callbacks\"\r\n \r\nAcceptance Criteria\r\n----\r\nOnce complete:\r\n  - [x] The test federate will use the `IMMEDIATE` callback mode, rather than `EVOKED`\r\n  - [x] A user can tell the federate to use `EVOKED` mode instead via a command line argument\r\n  - [x] There will be a clear message logged at the beginning of a run that says what mode is in use\r\n\r\nRemaining Tasks:\r\n - [x] Fix problem where federate hangs on resign\r\n - [x] Remove the current \"slow down\" code in the Throughput Test (sleeps briefly every so often to slow things down slightly and prevent openlvc/portico#74 from happening)\r\n - [x] Update shell scripts for new command line arguments (and better doc for `loop-wait`)\r\n - [x] Fix crash in federate caused by trying to send when there are no threads available in the pool"}}