This is to address issue #124 . The idea has two-folds:
For client side commands sent into the flume channel, we use a socket to trigger an event. (Unfortunately flume channel itself does not implement AsRawFd trait and does not support polling event together with existing mDNS UDP sockets.
For other timing based tasks, we store a simple u64 time for triggering them and uses timeouts to wait on them together with the sockets.
After this change, everything in the daemon run loop will be event driven (i.e. reactive) and have reduced latency.
This is to address issue #124 . The idea has two-folds:
For client side commands sent into the flume channel, we use a socket to trigger an event. (Unfortunately
flumechannel itself does not implementAsRawFdtrait and does not supportpollingevent together with existing mDNS UDP sockets.For other timing based tasks, we store a simple
u64time for triggering them and uses timeouts to wait on them together with the sockets.After this change, everything in the daemon run loop will be event driven (i.e. reactive) and have reduced latency.