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.
