Re: Sockets in C++?
On Apr 12, 4:41 pm, gi3nos...@mariani.ws (Gianni Mariani) wrote:
James Kanze wrote:
On Apr 12, 6:50 am, gi3nos...@mariani.ws (Gianni Mariani) 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,
and this is a problem because ?
Are you serious. My code is called, asynchronously, in a
different thread, and I don't even know that the application is
multithreaded? That can't work.
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
shutdown.
Ah, that's called a destructor.
I'm not sure I like that, at all. What happens if the other
thread doesn't collaborate?
Some programmers object to that and
want a special call, however I find that whenever I want to shut down I
also want to destuct and so the destructor is an excellent was to signal
a "thread" object to get out quick.
Yes, but I don't want to destruct until the other thread is good
and ready. In fact, normally, it is the other thread that does
any destructing which concerns his objects.
The destructor will wait for the
thread to exit before the object is truly destroyed.
In other words, the program may hang, and never terminate.
Maybe I see this as a solved problem and I don't get it.
Maybe you've just not pushed it to the limit, to see what
happens. Using destructors to terminate threads is a definite
loser.
--
James Kanze (GABI Software) email:james.kanze@gmail.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:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]