On Fri, 15 Oct 2010 08:03:21 +0400, Sean Kelly <[email protected]> wrote:

Andrei Alexandrescu <[email protected]> wrote:
On 10/14/2010 07:50 PM, Denis Koroskin wrote:
On Fri, 15 Oct 2010 03:08:23 +0400, Andrei Alexandrescu
<[email protected]> wrote:

http://docs.google.com/viewer?a=v&q=cache:K15RE_6zxSwJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.134.4874%26rep%3Drep1%26type%3Dpdf+zero+copy+i/o&hl=en&gl=us&pid=bl&srcid=ADGEESjBkiUxG4hRImVjOFy886GrJxRuhFcePjbadiUw9h1c_iicbhhArOgd55vpk0tP6ST4KjhY1j6rl1_PN-msIExUvxSPJWuXfQTbljj4ZYyutY6wvp3mc3t2LuA2-5kKPbbEp7z6&sig=AHIEtbSmuH-Y2AGdwSQxyJcbBXLRB3mJdg



Andrei

That paper is an ancient one and the API they demonstrated isn't a
> good
one.

What is a better, more recent one? I noticed that libfbufs has little
traction (googling for it only reveals 4 results) but the paper is
quoted by 63 others, so it's fairly influential.

Perhaps not terribly relevant, but IOCP on Windows does this. To perform
an asynchronous read you supply the buffer to recv and then an event is
signaled when the read completes. The same API works for file io and
there's support for scatter/gather as well. It makes for a more
complicated program though.

We are using IOCP for a game server with a great success. I'm not even sure we could achieve the same level of latency if we were using Linux and epoll.

I've implemented a Stream API (FileStream and SocketStream) on top of IOCP (both sync and async), and it doesn't complicate a program when used right. Automatic thread pooling for event callbacks is very handy, and since events for the same socket don't overlap you don't even need to synchronize anything but global state (in which case a simple ReadWriteMutex is more than enough).

Unfortunately, I'm not sure how to integrate that concept into D2 design. Even though events don't overlap, the callback thread is always different and as such thread local variables are unaccessible. I was thinking about dynamic thread local variables switching, but Walter says it is either highly inefficient or impossible to to implement.

Reply via email to