|
From: Lucio A. I. A. <l.i...@gm...> - 2016-11-27 21:01:55
|
On 27.11.2016 01:44, Alexandre Ferrieux wrote: > For the lazy ones like me, could you sketch in a few words how you > managed to handle interthread communication without that extra thread, > without consuming O(Nthreads) extra fds, and without contention (all > threads waiting on a single "bus" fd for interthread comm) ? On 27.11.2016 12:18, Donal K. Fellows wrote: > On 27/11/2016 00:44, Alexandre Ferrieux wrote: >> without consuming O(Nthreads) extra fds > > Without having studied the code in depth, I'd expect with epoll() for there to be one extra FD per thread (for that thread's epoll handle). On the other hand, without the hard limit imposed by select(), that's much less serious. There is no need for IPC between threads in order to do I/O; w/o the notifier thread, waiting threads call epoll/kqueue system calls themselves for the file descriptors they own. As no file descriptors (including the epoll/kqueue fd) are shared (implicitly,) there is no contention issue. While epoll_ctl/kevent calls can be issued whilst another thread is blocking on epoll_wait/kevent w/ the same epoll/kqueue fd, removing the notifier thread (and its support code/variables) would significantly reduce code size and complexity. I may have misunderstood the purpose of the notifier (thread,) however. I have not noticed any interthread IPC logic in unix/tcl*Notfy.c. Perhaps someone else on this list may enlighten me. |