|
Boost : |
From: Boris (boris_at_[hidden])
Date: 2005-03-05 06:21:34
Cory Nelson wrote:
> Something .NET doesn't have (but Win32 and Linux do), is I/O
> completion ports. For a high-performance server app, they beat pretty
> much everything. It would be great to see this get into a boost
> library, and trivial to implement them using select/poll in platforms
> that don't support true completion ports.
If we accept two models - synchronous and asynchronous - the second one
could be implemented with I/O completion ports if available. That's the .NET
approach, and Microsoft's .NET implementation is based on I/O completion
ports.
The socket class in .NET has two kinds of read/write-methods:
- For synchronous access: Send() and Receive() (it depends on a property
called Blocking if they block or don't)
- For asynchronous access: BeginSend() and BeginReceive() (a delegate aka
function pointer has to be passed to them which is then called when data is
available)
Advantage of this interface is that there are really two kinds of I/O
models. It depends on the implementation if asynchronous access is based on
multiplexing, aio, I/O completion ports etc.
The AsynchSocketBase concept seems to be built on this idea:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/AsynchSocketBase
I like this idea as otherwise we end up with a socket class which has to
provide read/write-methods for every I/O model. Eg. the
AcceptorSocketConcept at
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/AcceptorSocketConcept
has two accept() - one for blocking, one for non-blocking. If a socket class
supports every I/O model explicitly it will get a fat interface.
Boris
> [...]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk