On Apr 4, 2011, at 2:16 AM, KiberGus wrote:
> Remove static keyword from Connection::thread_start(). So it would
> be impossible to call it without creating a connection.
The first problem with that is that it would change the library ABI. Since MySQL++ v4 is
somewhere past the development horizon, I wouldn't make any plans based on this happening.
Second, it means that if a thread gets a Connection created by another thread, you've
increased the risk of problems because there's nothing forcing you to call thread_start()
before you begin using it. By leaving this as a static function, we at least drop a strong
hint that you should call it first.
> I don't think, that conenction pool is a reasonable choice for non
> threaded applications.
I don't see that this observation has any bearing on the matter. It may be true, or not,
but it's orthogonal to the issue at hand, as far as I can see.
> So it would be good if it would to call
> Connection::thread_start() on each ConnectionPool::grab()
> automatically. Then it would be impossible to forget to call
> thread_start() which should be done always.
I don't know if you realize it, but you're going around in a circle.
If the MySQL++ ConnectionPool implementation is to call Connection::thread_init(), it
*must* be static if it's to be called before the low-level IPC connection is established,
because it doesn't create connections. The ConnectionPool subclass creates and starts the
connection, and it is free to implement threading correctly already, because it knows how
the program it was written for works.
> As another way of solving the problem is to make
> DBDriver::thread_start() call my_init() every time.
Try it. Does it actually banish the symptom in your program?
> So the ideal working solution of this issue is to call my_init at the
> very beginning, before any threads are created. I think, that this is
> not what mysql++ can care about. But this fact should be reflected in
So what you're saying is that my option #2 is the only one that can be guaranteed correct?