From: Warren Young
Date: May 15 2009 1:19pm
Subject: Re: Segfault using thread_start
List-Archive: http://lists.mysql.com/plusplus/8567
Message-Id: <4A0D6BDC.7090600@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael wrote:
> 
> Hmm, the underlying C library documentation states, that
> mysql_library_init has to be called before any other mysql* function
> call.

...but only if you don't create a connection in that thread first.  This 
is why your "temporary fix" above worked, and also why most people never 
run into this.

> So your solution would be making the user explicitely call it
> through DBDriver? 

No, it would give people the option to call it if for some reason they 
had an architecture like yours, where a thread might need MySQL++ access 
but isn't creating its own Connection first.

> I personally feel that it would be much more user
> friendly, if mysqlpp would do the bookkeeping automatically

Easy to say.  The hard part is coming up with a way to make it so.

One way, if you're using ConnectionPool, is to add these calls to your 
custom ConnectionPool derivative, one on the ctor, the other in the 
dtor.  Given the typical pattern where there is only one pool and it is 
the first MySQL++ object created and the last to be destroyed, this 
should work fine in almost all cases.

If you're not using a connection pool, what then?  Maybe a custom 
MySQL++ object that you just create on the stack in main()? 
mysqlpp::AlphaAndOmega?

> Whatever the solution will look like, it might me good to upgrade the
> documentation and point that out in the multithreading chapter of
> mysqlpp. Depending on the execution path, segfaults might hitting users
> unexpectetly.

The documentation is part of MySQL++ itself, and MySQL++ releases never 
consist of just documentation updates.  Since the very next release will 
have the fix, the doc changes can just be part of that.