![]() | |||||||||||||
Messages in this thread |
On Mon, 27 Dec 2004, Paul P Komkoff Jr wrote: > I am trying to implement a multithreaded event loop using epoll. So, I > have 2 kind of events. First, there are conditions on fds I have > (listener sockets, client connections, my connections to other > clients). Second, I need to have some kind of priority queue into > which I can push forthcoming timed events. > > In case of single-threaded server, this is fairly trivial. I just need > to make heap queue and add its 1st (i.e. minimal) element as timeout > to each next epoll_wait call. When some condition breaks the wait, I > can always do find_min and wait again with new timeout. > > Things become complicated when I need to scale. So, without this > timeout cruft, I can just add proper locking around my data structures > but main epoll_wait loop is multithread-aware, e.g. it will retrieve > different events for different waiting threads (to be absolutely fair > with you, I did not implemented this part yet, but I assume that some > combination of edge triggered + one shot epoll will do the trick). > But, if using heap priority queue to manage timed events, I need to > wake up each waiting thread when any event was added to the heap > before one that was minimal. One solution (if you really cannot scale using multiple processes) is the one that you're describing, where you have many threads doing epoll_wait. You have to be careful to not fetch too many event on a single wait (preferably one), otherwise you can end up with period of time with pending events on a single thread, while others are free to spin. If the timers that you are using are simply to timeout pending operations, the timer resolution does not need to be that high, so you could use a maximum timeout of a second or so for epoll_wait (and handle timers like you planned). Another solution would be to have a single epoll_wait loop thread that feeds your threads that are waiting on a mutex, protecting an event queue from which threads pull events. This will make timeout handling somehow easier, but delivering an event would mean a ctx switch to wake the epoll_wait thread, plus another one waking a processing thread. > Another solution proposed by my poor brain is - to have alive thread > which will handle this priority queue, and have one fifo fd in my > epoll set dedicated to this purpose. Priority queue management thread > will write single char to that fd when some timed event needs to be > processed. > > Doing some google search, I've found this message: > http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.3/2416.html > Things can be much easier if there was timer kernel object (or its > equivalent). Can anyone give me some advice - how I should solve this > problem? Like lingering IRQs, nobody cared :-) Linus also proposed a "signal fd", that could have been used for timers, but nobody showed interest either. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 14:09 [from the cache] ©2003-2008 | |||||||||||||