Mirai Re-design

[shikokuchuo]

Which was always in the works even prior to the 0.8.0 release. Inviting @wlandau.

This uses synchronisation primitives from the NNG library newly-exposed in nanonext (to be 0.8.1). We should confirm we have all we need for mirai before we release nanonext.

[shikokuchuo]

9a0f2a6 begins the journey.

Re-writes server() switching from a blocking receive to a waiting on a condition variable. This condition variable is signalled either by an async recv or a pipe notification event (on pipe removal). When this happens, we simply check to see if the aio is unresolved - if it is then it is for sure a pipe event and we exit.

This leads to much safer behaviour. For example we can now have a local dispatcher with daemons, kill the dispatcher process and the daemons will all exit (was not the case previously).

Also no need to send any exit signals!! A bit less magic, but bigger overall magic!

Another side effect is that the server process exits gracefully and silently in all scenarios now rather than through error.

@wlandau when you have the chance to test the new behaviour, it might allow you to remove some of your safeguards in crew. I am doing this piecemeal, but when I have finished what I already have planned, we can look at what else is needed to make the overall integration with crew better.

[shikokuchuo]

All of these will be addressed in good time. The dispatcher will exit in the same way as servers, so no need to worry especially about a dispatcher process. Both dispatchers and servers will exit if the main session is closed (forcibly or not).

[wlandau]

Thank you, I am very much looking forward to that! On my end, I think the last known issue is wlandau/crew#51, and at the moment I have no idea whether it is caused by crew or mirai.

[shikokuchuo]

wait a couple more days for the non-polling dispatcher. it will be a game-changer. congrats on crew 0.0.4 on CRAN! It's been a real pleasure working together on this.

[wlandau]

Such a game-changer. As I write documentation on custom worker launchers in crew, I am realizing how liberating it will be to rely entirely on the mirai dispatcher in order to terminate servers. If crew does not have to manually terminate its workers, then writing these plugins will be a whole lot easier and more efficient, and more people from the community will be able to participate.

[wlandau]

At the very least, I can make manual worker termination optional. Some authors might want to add it in the case when startup times are really long, and some authors may not be able to add one, depending on the platform.

[shikokuchuo]

With shikokuchuo/nanonext#5073346 we should now be up to the task.

Pipe events (i.e. disconnects) can be easily distinguished as they can be set to trip a flag. The wait() will then return FALSE instead of TRUE.

This allows us to write clean code such as:

wait(cv) || break

And we don't need to check for unresolved status any more.

[shikokuchuo]

It's almost comical how I can keep adding to my arsenal. e726170 is not enough...

[shikokuchuo]

turns out fc08c77 was needed rather than the previous commit. This is now enough :)

[shikokuchuo]

This has come in one drop as lots of stuff tied together, but the non-polling dispatcher is complete in 3891ddf.

Has gone through a fair amount of stress testing and passes well.

This throughput test is now instantaneous:
wlandau/crew#41 (comment)

My original test which spurred all of this, now returns an overhead of an incredibly miniscule 13 ms on my laptop!!
#18 (comment)

In no particular order:

'pollfreqh' and 'pollfreql' arguments removed as have no more meaning. 'exitlinger' removed from dispatcher as no longer applicable there. These should be backwards compatible as extra arguments should get lost and ignored in the '...'.

No minimum socket lifespan needed. There is now a little ack exchange between client and dispatcher to guard against hanging processes such as: wlandau/crew#41 (comment). Manually-launched dispatchers are still possible though and does not have this to allow normal operation.

dispatcher and server will now exit gracefully when parent process exits/crashes etc. (whenever the connection is dropped). This should help minimise orphan processes.

Self-repairing local daemons (when auto-launched) was a nice proof of concept, but removed to reduce complexity and enhance overall logic flow at dispatcher. Would have been rarely needed for the local cases.

'exitlinger' applicable now only to server() when time or task outs occur to ensure data gets sent back, not when client/dispatcher exits. Default is now set at 1000ms - only needs to be set wider if returning multi-GB objects. It has not been possible to eliminate this entirely for reasons I will detail in a new issue.

dispatcher() now uses cvs and pipe-notify() to capture all server connects and disconnects - and stats on instances are now accurate even if servers just connect and disconnect repeatedly. It no longer uses the NNG stats interface which we found to not really be real-time. And a nice side effect is getting the connection status is now 1-2 orders of magnitude faster!

[wlandau]

All these changes are wonderful! crew is so much faster, and the dispatcher is snappy and trustworthy in terms of exits. I did submit a couple bug reports, but I can work around those in crew. wlandau/crew#51 still persists, but that may be something in crew in not mirai, I still do not know.

[shikokuchuo]

All these changes are wonderful! crew is so much faster, and the dispatcher is snappy and trustworthy in terms of exits.

Thanks! I knew what I wanted conceptually, but couldn't be certain if it was going to be actually feasible. In the end it turned out to be fine, although involving quite a bit of engineering at {nanonext}. A straight wrapping of NNG's functionality would not have been up to the task - the implementation is highly customised to our needs!