Re: Sockets in C++?
On 4/12/07 11:53 AM, in article
email@example.com, "James Kanze"
On Apr 12, 6:51 am, n...@animats.com (John Nagle) wrote:
Mathias Gaunard wrote:
On Apr 10, 8:56 pm, John Nagle <n...@animats.com> wrote:
Once you start using a callback-based framework, you have to do
everything that can delay via that framework. Otherwise you stall the
callback engine. So the introduction of a callback-based framework
determines the overall design of the program.
A call to an asynchronous I/O routine returns immediately, so even if delays
exist in the communications channel - the program itself is not delayed.
Moreover, it is not possible to "stall" an asynchronous I/O operation
because - being "asynchronous" - the amount of time needed for the I/O
operation to complete is independent of - and unaffected by - the program'
activities during the same span of time.
Even a program that processes callbacks at a leisurely rate, does not hold
up the I/O operation's completion. After all, the callback executes only
after the request has finished. So although a program may delay its
recognition of the completed I/O operation - it was not able to delay the
start of the the request itself.
An obvious solution is to run the whole engine in its own thread.
However, doing so automatically would reduce the user's control, who
couldn't choose on which thread (or pool of threads) he wants to run
Since the support for threaded execution is not a prerequisite of the asio
library: the only thing "obvious" about this proposed solution (for a
non-existent problem) is the impossibility of implementing it.
Then you have to address thread-safety issues. If you want
to change "asio" list of work to do, and it has its own thread, how and
what do you lock? "asio" would need a lock that's locked when
"asio" isn't in its waiting state. That doesn't seem to have been
So the only effect of implementing this "solution" is to create all sorts of
potential problems and needless complications - none of which existed in the
Part of that should be asio's problem, not the users. But you
do have to face the fact that you force threads down the user's
throat, whether he wants them or not, and that the user must
take into account that he doesn't know in what thread the
callback may be executed, which seriously limits his options,
and means that he suddenly has to worry about synchronizing
things. (Note that it can be very tricky, since the callback
may also be called in the same thread. At a moment when the
thread holds the locks needed. And that those locks are not
The callback is always executed on the same thread that made the I/O request
(and likely the only thread in the entire program). So what would these
locks be doing, exactly?
Personally, I'd rather expose the threading: make the io
blocking, and leave it up to the user to split it off into a
second thread if he needs non-blocking.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:firstname.lastname@example.org ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]