Messages in this thread | | | Date | Fri, 18 Oct 2002 14:55:28 -0400 | From | Mark Mielke <> | Subject | Re: epoll (was Re: [PATCH] async poll for 2.5) |
| |
On Fri, Oct 18, 2002 at 10:41:28AM -0700, Davide Libenzi wrote: > Yes, I like coroutines :) even if sometimes you have to be carefull with > the stack usage ( at least if you do not want to waste all your memory ). > Since there're N coroutines/stacks for N connections even 4Kb does mean > something when N is about 100000. The other solution is a state machine, > cheaper about memory, a little bit more complex about coding. Coroutines > though helps a graceful migration from a thread based application to a > multiplexed one. If you take a thread application and you code your > connect()/accept()/recv()/send() like the ones coded in the example http > server linked inside the epoll page, you can easily migrate a threaded app > by simply adding a distribution loop like :
> for (;;) { > get_events(); > for_each_fd > call_coroutines_associated_with_ready_fd(); > }
If each of these co-routines does "while (read() != EAGAIN) wait", your implementation is seriously flawed unless you do not mind certain file descriptors that may have lower numbers to have a real time priority higher than file descriptors with a higher number.
If efficiency is the true goal - the event loop itself needs to be abstracted - not just the query and dispatch routines. Using /dev/epoll in a way that it is compatible with other applications is an excercise in abuse, that will only show positive results because the alternatives to /dev/epoll are ineffective, not because /dev/epoll is a better model.
I like the idea of /dev/epoll - which means that if I used it, I would implement an efficient model with it, not a traditional model that through hackery will function transparently using /dev/epoll.
But that might just be me...
mark
-- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them...
http://mark.mielke.cc/
- 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/
| |