Re: [PATCH] /dev/epoll update ...

Davide Libenzi (davidel@xmailserver.org)
Mon, 24 Sep 2001 13:04:53 -0700 (PDT)


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/