List:MySQL++« Previous MessageNext Message »
From:KiberGus Date:April 4 2011 8:16am
Subject:Re: thread_start() should ALWAYS be called after mysql_init()
View as plain text  
>From: Warren Young <mysqlpp@stripped>
>To: plusplus@stripped
>Date: Wed, 30 Mar 2011 21:08:08 -0600
>Subject: Re: thread_start() should ALWAYS be called after mysql_init()
>On Mar 30, 2011, at 2:49 PM, KiberGus wrote:
>
>> I tend to interpret it as a requirement that application MUST start
>> it's work with library with call to  mysql_init(),
>> mysql_library_init(), mysql_server_init(), mysql_connect() or
>> my_init(). And then it is documented feature of mysql library and bug
>> is in mysql++ rather than in mysql_thread_init.
>
>There are two ways to fix it:
>
>1. Make the MySQL++ docs reflect the underlying C API requirement
>
>2. Somehow protect all calls to MySQL++ so that it inits the underlying C API library
> no matter which code path you use, thereby wrapping up all this complexity inside
> MySQL++.
>
>It sounds like you want #2.  That sounds like a fine idea, but personally, I don't use
> threads with MySQL++ -- as if you you'd never guess from the second paragraph of the
> userman chapter you link to -- so I have >little incentive to fix it.  It's your itch. 
> Scratch it.
>
>If you leave it to me, I'll likely either continue to ignore the issue or do #1.

Well, I'not a guru in mysql threaded clients and I don't know much
about pitfalls in mysql C API. So I'm not sure about how this fix can
be implemented.
There are two quick way to fix the issue. First one is:
1)  Remove static keyword from Connection::thread_start(). So it would
be impossible to call it without creating a connection. And my_init is
automatically called on connection creation.
2) I don't think, that conenction pool is a reasonable choice for non
threaded applications. 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.
3) Change documentation to represent this changes.

As another way of solving the problem is to make
DBDriver::thread_start() call my_init() every time. It is safe to call
my_init several times and it does not consume much time.

But it looks like this methods are not thread safe because mysql_init is not:

  if (my_init_done)
    return 0;
  my_init_done=1;

And line 647 of libmysql.c:
mysql=mysql_init(mysql);                      /* Make it thread safe */

makes me think, that mysql developers prefer just to live with that.
And threaded application may fail if two threads try to establish the
first connection at the same time.


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
documentation.

Thaks.
Thread
thread_start() should ALWAYS be called after mysql_init()KiberGus30 Mar
  • Re: thread_start() should ALWAYS be called after mysql_init()Jonathan Wakely30 Mar
    • Re: thread_start() should ALWAYS be called after mysql_init()KiberGus30 Mar
      • Re: thread_start() should ALWAYS be called after mysql_init()Warren Young31 Mar
Re: thread_start() should ALWAYS be called after mysql_init()KiberGus4 Apr
  • Re: thread_start() should ALWAYS be called after mysql_init()KiberGus4 Apr
  • Re: thread_start() should ALWAYS be called after mysql_init()Warren Young4 Apr
    • Re: thread_start() should ALWAYS be called after mysql_init()Warren Young4 Apr
Re: thread_start() should ALWAYS be called after mysql_init()Raymond Boettcher5 Apr