From: Cory Nelson (phrosty_at_[hidden])
Date: 2005-03-05 01:26:24
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.
On Sat, 5 Mar 2005 02:18:47 +0200, Boris <boris_at_[hidden]> wrote:
> Caleb Epstein wrote:
> > On Thu, 3 Mar 2005 01:13:58 +0200, Boris <boris_at_[hidden]> wrote:
> Caleb, thanks for your comments! There is not much feedback so appreciate
> any comment. I wonder if there's a lack of interest or some resignation as
> the socket stuff is in the Wiki for ages without any progress.
> > [...]
> > * blocking/nonblocking mode must be selectable at run-time. Having a
> > default selectable at compile time is fine, but not allowing a switch
> > at runtime would be too limiting.
> You are right, I agree.
> > * Don't model sockets on iostreams. They don't model non-blocking I/O
> > correctly (see Jonathan Turkanis's recent posting on the evolution of
> > the Boost.Iostreams interfaces). Simple methods called read and write
> > should be sufficient.
> I agree again. The operators in class socket are an example to show where
> read- and write-methods will be implemented (whatever they will look like).
> > * Server should probably be a factory of sockets. I don't think
> > client and server should be concepts at the root of the hierarchy.
> I'll have a look at the net library in Java and .NET. I hope to create UML
> diagrams for these libraries, too. Then we should get an insight into
> differences and possible advantages of their designs. I'll post to this
> newsgroup whenever I update the Wiki.
> > * To implement a scalable server-side application there must be
> > support for IO multiplexing (e.g. select/poll/etc) and this should be
> > considered in the design.
> That's what the class multiplexing represents (in namespace
> By the way, what do you think about the .NET way? In .NET there are only two
> models: synchronous and asynchronous. Synchronous is the same as blocking
> but asynchronous depends on the implementation (from multiplexing to
> signal-driven to real asynchronous is everything possible). Does it matter
> to a library user how asynchronous is actually implemented?
> > * Picking nits, they are "Berkeley" sockets, not "Berkely".
> Thanks, corrected!
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk