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.
