Messages in this thread | | | Date | Mon, 24 Sep 2001 13:04:53 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [PATCH] /dev/epoll update ... |
| |
On 24-Sep-2001 Eric W. Biederman wrote: >> Coroutines or not, this does not change the picture. >> All multiplexed servers have an IO driven scheduler that calls >> code sections based on the fd. >> Obviously if you've a one-thread-per-socket model, epoll is not your answer. > > A couroutine is a thread, the two terms are synonyms. Generally > coroutines refer to threads with a high volumne of commniucation > between them. And the terms come from different programming groups. > > However a fully cooperative thread (as is implemented in the current > coroutine library) can be quite cheap, and is a easy way to implement > a state machine. A pure state machine will have a smaller data > footprint than the stack of a cooperative thread, but otherwise > the concepts are pretty much the same. Language support for > cooperative threads, so you could verify you wouldn't overflow your > stack would be very nice. > > So epoll is a good solution if you have a one-thread-per-socket model, > and you are doing cooperative threads. The thread being used here is > simply a shortcut to writing a state machine.
If you'd be the os i guess you'd not say the same :) It was pretty clear the model i meant was one real thread/process per fd. The main difference with coroutines is that the /dev/epoll engine become the scheduler of your app. It's also clear that you can avoid the coroutines by writing a state machine. There's a HUGE memory save with the stack removal that you pay with a more complicated code.
- 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/
| |