Hi,
This is a continuation of another thread called 'thread_start'.
Sorry I did not just respond to the previous thread instead of
starting this new one, but I was subscribed to the digest version
of the mailing list and I don't know how to respond to one
particular message in this case. I resubscribed to the normal
version now, so future responses should be better.
>> 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.
I don't agree. Consider the following scenario: (please forgive my ascii
art, look at this with a fixed size font)
+--------------------+---------------------+
| thread1 | thread2 |
+--------------------+---------------------+
| start | |
| ..work.. | |
| grab (iteration 1) | | <-- new connection is created
| ..work.. | start |
| release | ..work.. |
| ..work.. | grab (iteration 1) | <-- connection is reused
but switched threads!
| grab (iteration 2) | ..work.. | <-- new connection is created
| | |
Maybe I'm missing something, but I think the above is not
unlikely to happen.
> 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 don't understand how you can call connection->thread_start() on
entry of the worker_thread because you only have the connection
instance after calling grab()?
> 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.
I asked this question because I want to update my own connection
pool implementation that I used with version 2. (I want to continue
using this implementation because of some extra features). I was
thinking about adding the thread_start and thread_end calls to my
versions of the pool->grab and pool->release functions.
>> 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.
Similar as above. If you release the connection, how can you
call one of its methods?
> 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.
Granted, but I currently don't see any other option. Maybe these
functions can be made static members of Connection? Since they
only call mysql_thread_end and mysql_thread_start and do not act
on a particular handle. I don't know if this is an option because I
don't really know what these functions do.
Best regards,
Tom
