Eio bindings Zmq

[andersfugmann]

Eio aware bindings for zmq.

The changes includes factoring out concurrent bindings (i.e. lwt/async/eio) to allow Eio bindings to follow the same interface.
Commits can be read one by one.

During testing I was puzzled that the Eio tests were significantly slower than the lwt/async tests, however this was due to a fault in the original tests where the delay in sending / receiving was only applied for the first loop iteration. This is also fixed.

[andersfugmann]

I don't want to just add reviewers, so I kindly ask either @Leonidas-from-XIV or @AndreasDahl to give a review on this.

[Leonidas-from-XIV]

I am not sure I am the best person to review this, since I don't know very much about Eio but here's at least my observations from the code.

[Leonidas-from-XIV]

I don't understand the Eio terms here, what does the Switch do?

[andersfugmann]

Fibers is a lightweight thread. A switch is a collection of fibers and will run until all fibers has ended or cancelled. Daemon fibers will automatically be cancelled once all "regular" fibers has ended.

The construct here is made to control lifetime of the two fibers started. Once the main loop exits, the signalling daemon fiber will be automatically be cancelled. Creating a promise allows the caller of close to wait until the event loop has ended (all handlers completed).

Close is meant to be a nice way to close the socket allowing all readers and writers to end. Its also possible to cancel a switch. If the parent switch (passed as arg this function) is cancelled all child fibers and switches are cancelled.

I hope this explains the construct of the fork -> switch -> fork.

[Leonidas-from-XIV]

run implicitly creates a dependency on test, so this could be skipped.

[andersfugmann]

I'm not sure I understand. Can the rule be skipped altogether?
Tried to replace the block with

(rule
 (alias runtest)
 (action
  (run test.exe))
 (package zmq-eio))

But that does not work

[andersfugmann]

Thanks a lot for your comments @Leonidas-from-XIV - Really appreciated!

One question about close semantics. In lwt/async, if the socket is closed any deferreds waiting on either send or recv will never be resolved.

In zmq-eio, close will wait for all current sends and receives. Any requests made after the socket has been closed will raise Closed. I'm considering changing the semantics to raise Closed for all pending requests also when/if the socket is closed. What do you think? What semantics would you expect?

[AndreasDahl]

Looks good to me