From: Scott Woods (scottw_at_[hidden])
Date: 2005-08-03 21:30:17
----- Original Message -----
From: "Pedro LamarÃ£o" <pedro.lamarao_at_[hidden]>
> > Any networking library which does not have non-blocking asynchronous
> > network I/O is, IMO, doomed to general non-use. But go ahead and create
> > you like and see how many end-users adopt it for their networking needs.
> I'm sincerely fascinated by this comment, which I feel represent how
> almost everyone in these networking threads feel.
> I must be absolutely ignorant in what constitutes a performant
> networking application, if multiple threads blocking on IO is a design
> doomed to general non-use by those writing multi-session applications.
If "multiple threads blocking on IO" means "thread-per-session" then
that is not scalable to some of the larger applications.
> Can you explain to me what is fundamentally wrong with this model, and
> how the use of asynchronous primitives or the non-blocking mode is so
> vastly superior?
There's nothing "fundamentally wrong" with it. As you say, it works.
also "works" but this means different things each time. IMO the entire
process of software development (design through to maintenance) is affected
by whether a selected network library is blocking or non-blocking. To
blocking libraries seem to constrain the process while non-blocking provides
so much freedom that it can bite.
The above paragrah is about the long term significance of non-blocking vs
blocking. I believe you are also facing the issue of library
if you ultimately want to provide both a blocking and non-blocking API it
is less difficult to imagine a non-blocking API over a blocking API than the
other way around.
A library developed with no regard to non-blocking will be an island; it
force the development of a separate non-blocking network library.Whether
that arrangement is truly sub-optimal? I dont know.
For me at least, a non-blocking network library is the "pot of gold". Its
my more ambitious projects are screaming out for and what would make my
code so much more appealing. Which doesnt mean to say that I dont write
blocking test programs a month.
> I would sincerely like to know, because I've been writing those for some
> time, and, though our clients aren't complaining, perhaps I could be
> delivering more.
> Pedro LamarÃ£o
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk