MySQL Lists are EOL. Please join:

List:MySQL++« Previous MessageNext Message »
From:Tom Moers Date:March 7 2008 9:32am
Subject:Re: thread_start
View as plain text  

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              |                     |
|           |                     |
| grab (iteration 1) |                     | <-- new connection is created
|           | start               |
| release            |            |
|           | grab (iteration 1)  | <-- connection is reused 
but switched threads!
| grab (iteration 2) |            | <-- 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,

thread_startTom Moers6 Mar
  • Re: thread_startWarren Young7 Mar
Re: thread_startTom Moers7 Mar
  • Re: thread_startWarren Young7 Mar
    • Re: thread_startTom Moers7 Mar
      • Re: thread_startWarren Young7 Mar
        • Re: thread_startTom Moers7 Mar
          • Re: thread_startWarren Young7 Mar
            • Re: thread_startWarren Young7 Mar