Re: Sockets in C++?
On Apr 13, 12:46 am, Sebastian Redl <e0226...@stud3.tuwien.ac.at>
On Thu, 12 Apr 2007, James Kanze wrote:
If the callbacks are based on a threading model; i.e. the event
control runs in its own thread, then you have to take into
account the fact that the user's callback may be (and probably
will be) called from a thread the user doesn't even know about,
Not in asio. It guarantees that callbacks will only be called on threads
explicitly given to the event manager (the io_service in asio terms) via
its run() method.
In other words, the problem has been recognized and addressed.
That's very good.
and you have to provide a mechanism for the user to stop the
thread (which he doesn't know about) in order to ensure clean
Not really. You only need to provide a way to signal the event
manager to stop.
And it takes care of the threads, transparently?
Asio does that automatically when no work is left (which should be the
normal way of shutting down for such systems) or by calling the
Just curious, but "no work left" means what? My vision of this
(perhaps mistaken) is that of a server, which is up 100% of the
time, waiting for connections.
So the remaining complaint is that you need to give the event manager a
thread in the first place, one that can't do other things (like go into a
native Win32 event loop).
This means, for example, that I can't use asio in a single
threaded application? (Unless an application needs to be
multithreaded, I prefer to keep it single threaded.)
Bottom line: if asio had a non-blocking run() that just executes
immediately available work and returns, I think everyone ought to be
Even though personally I don't think a polling approach would be terribly
It depends. It would work if you had some way of waking up the
main loop when there was an incoming event to be treated.
The problem with standardizing sockets, as I see it, is that
there are two incompatible approaches, and both have their
advantages. From what you've just said, I think that asio
adopts one approach, which is fine, as long as the other
approach (single thread, with main process loop) is available as
James Kanze (GABI Software) email:email@example.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ 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 ]