Thread start functions and external C linkage (VDR starts it's threads "incorrectly")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sascha Volkenandt wrote:
> Hi everyone, hi Klaus,
> 
> while discussing a paper about multithreading with pthreads, some people 
> pointed out that it is not legal regarding standard C++ when using a static 
> member of a class as a thread start function.
> 
> The reason is that a thread start function handed to pthread_create MUST have 
> external C linkage, which is not guaranteed to be the case with static 
> members. In fact, many compilers declare such members with the same calling 
> conventions that an extern "C" function uses, but the standard doesn't 
> require this. Indeed, there are (according to external informations) 
> compilers that act differently here.
> 
> To fulfill the requirements of the standard, VDR's thread start function 
> should have the following signature:
> 
> extern "C" void *StartThread(cThread *Thread);
> 
> class cThread {
>   friend void *StartThread(cThread *Thread);
>   /* ... */
> };

This would allow anybody to do

   cThread t;
   StartThread(&t);

which I don't think would be a good thing to do.

Any ideas how to prevent this from happening?

Klaus

> Don't get me wrong, this is not a problem with current gcc versions, but... 
> Since the standard doesn't require gcc to behave the way it does, future 
> changes to the ABI could affect this region and could render current code 
> unfunctional...
> 
> Even worse, some implementations of pthread lack a construct that declares the 
> members of pthread.h extern "C" when compiled in C++ mode. (But this won't be 
> a problem here I guess, since I suppose VDR won't run on AIX, so, just for 
> the record).


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux