----- Original Message ----- From: "Pedro Lamarão" <pedro.lamarao@mndfck.org> To: <boost@lists.boost.org>
Any networking library which does not have non-blocking asynchronous support for network I/O is, IMO, doomed to general non-use. But go ahead and create one if 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.
"performant"? 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. Non-blocking 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 generalize; 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 (de-)composition; 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 will 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 what 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 several blocking test programs a month. Scott.
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: