Warren Young wrote:
> 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?
I though more in the lines of mysqlpp checking if it already called
mysql_init and if not, it will and also setup an onexit handler, which
is removed if you call an library_end abstraction.
>
>> 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.
>
