It allows for simpler client code because the client can assume that
when cancel() returns the callback will not run and thus there's no
need to handle the race between timer teardown and execution of the
callback.
The imperative form suggests that in addition to returning a future it
performs some action and thus is needed regardless of whether we want
to add a callback or not. But in fact it does not do anything, just
gives away a future.
Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>
With the current listen() -> future<connection> interface, if a new connection
is established before the connection handler is able to re-register for the
port, we have to drop the connection.
Fix by adding a queue for accepted connections, and switching to the more
standard listen() -> accept() -> future<connection> model.
Instead of returning the Unix-tied pollable_fd, return an abstract
server_socket class which is then implement atop pollable_fd, but can
be replaced with a native implementation.
Instead of returning a future<packet>, return a future<> (signifying data
is available) and provide a read() method.
This is useful in case the user wants to consume more or less than exactly
one packet.
