From: Warren Young
Date: March 7 2008 7:27am
Subject: Re: thread_start
List-Archive: http://lists.mysql.com/plusplus/7501
Message-Id: <47D0EE64.2060805@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Moers wrote:
> 
> It is stated that thread_start() needs to be called whenever
> you start using a connection in a different thread than the one
> that created it. So, shouldn't the thread pool example in this
> section call thread_start right after calling poolptr->grab()

In this particular example, it's virtually certain that the first grab() 
call in each thread always creates a Connection, thus initializing the 
per-thread resources.  For this to not be the case, one of the threads 
would have to make it all the way to the release() call before all of 
the other threads have made their first grab().  Since the code between 
grab() and release() in each worker should take more time than is 
necessary for this to happen, we should be safe.

If you want to be pedantic, or you are trying to reuse this code in a 
heavily loaded system, yes, you should call thread_start() on entry to 
worker_thread().  (Not right before the grab() inside the loop!  More on 
this below.)

I will think about doing this in the example.  At the moment, I can't 
decide if it's just pedantry, or it actually speaks to a real problem.

> and thread_end before calling poolptr->release())?

No, the other way around: call thread_end() after the release(), outside 
the for loop, just before the thread returns.

It's not that it won't work if you tell the C API to start and stop the 
thread repeatedly inside the for loop, it's just inefficient.  It's 
allocating the same resource each time, so making it repeatedly 
reallocate it is just wasteful.