Re: Posix thread exiting and destructors
On Apr 11, 7:39 pm, "bjeremy" <bjer...@sbcglobal.net> wrote:
void Thread::start()
{
pthread_create(&thread, 0, Thread::dispatch, this);
Attention! This shouldn't compile (although g++ has a bug, and
doesn't detect the error). The type of function required by
pthread_create is `extern "C"', and a member function, even
static, can never be `extern "C"'.
Actually.. I haven't run it on a compiler that won't accept this..
MSVC, g++, gcc.. all seem fine with it...
I've not tried with VC++, but I know that this is a bug in g++.
Sun CC complains.
but I'll double check the
specs on this... I didn't see anything offhand that says I can not use
a static member... but if you can point me too a specific reference
that would be cool...
Well, technically, of course, it depends on the declaration of
pthread_create, and an implementation could overload it to take
either (knowing that behind the scenes there is no difference),
much in the same way the standard *requires* the library to
overload functions from the C library, like atexit, sort and
bsearch, which take pointers to functions. Neither Linux nor
Solaris do this, however, so it is probably best not to count on
it, and to just suppose that there is a single pthread_create,
declared:
extern "C" {
extern int pthread_create( pthread_t*, pthread_attr_t*,
void *(*)( void* ),
void* ) ;
}
Which means that the type of the third argument is `extern "C"
void* (*)( void* )'; only a function with "C" language linkage
can be used. (Note the end of =A77.5/1: "Two function types with
different language linkages are distinct types even if they are
otherwise identical.") Finally, the last normative sentence in
=A77.5/4 says "A C language linkage is ignored for the names of
class members and the member function type of class member
functions", so that even if you try to declare the static member
function to have "C" linkage, it is ignored. (I don't know the
reason for this last rule; it would make sense to allow static
member functions to have C linkage.)
[...]
Now.. if the OP is creating a TCP server, and its not a multi-core or
dual processor machine... I wouldn't use threads at all... its a
waste, multiplexing is much faster on a single processor...
Not necessarily. And multiple threads won't necessarily be
faster on a multi-core, here, since there is almost no CPU
involved anyway; it's all IO.
If it is
multi-core, the previous recommendation of the thread pool would
probably be the better design and also lets you sidestep the whole
issue of the thread destructor.
If you have the code for a thread pool handy, by all means use
it. Otherwise, I doubt that it's worth the effort necessary to
develop it.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34