b300ef08   
   From: vlukas@gmx.de   
      
   Rani Sharoni wrote:   
      
   > On May 14, 10:14 pm, Pete Becker  wrote:   
   >> The difference in the signatures of the called functions comes   
   >> about because thrd_create takes a function pointer of type   
   >> int(*)(void*); in C++, the std::thread constructor takes an   
   >> arbitrary callable type and an appropriate argument list.   
   >>   
   >> This isn't properly called "an incompatibility", however. The   
   >> underlying design models are quite different.   
   >   
   > I also noticed a potential abstraction penalty associated with   
   > std::thread.   
   > Per the C++ standard 30.3.1.2/4 (thread construction): The *new   
   > thread of execution executes* INVOKE(DECAY_- COPY(   
   > std::forward(f)), DECAY_COPY (std::forward(args))...)  with   
   > the calls to DECAY_COPY being evaluated in the constructing thread.   
   >   
   > This means that in general the caller thread has to wait for the new   
   > thread copying - serialization penalty that doesn't exist for the   
   > raw C interface.   
   Can you explain a bit more what exactly is the origin of the   
   performance penalty? You write that the caller has to wait for the new   
   thread to copy something - but I can not see why that is the case. As   
   is stated in the quote from the C++ standard above, the copies are   
   made in the calling thread.   
      
   Or is your point that copies are made at all?   
      
   [...]   
   > Example for why the wait is needed:   
   > struct A {};   
   > void func(A&) {}   
   I believe this is not a valid signature for a thread routine:   
   DECAY_COPY returns an rvalue, which does not bind to A&. A quick test   
   with GCC 4.7.0 seems to agree, with A& a compile error is reported,   
   A&&, A const& and plain A all compile.   
      
   > void f()   
   > {   
   >     A a = {};   
   >   
   >     // copy of 'a' is done by the new thread   
   >     // hence f() has to wait to keep the source alive   
   >     std::thread(func, a);   
   > }   
   As written above, I do not see any requirement that the *new* thread   
   makes any copy. A test with GCC 4.7.0 also shows that all copies are   
   made in the calling thread.   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)