Re: [Tcl-tdbc] tdbc::mysql and multiple threads...

[Kevin K. <kk...@ny...>]

On 09/02/2016 08:40 AM, Georgios Petasis wrote:
> Dear Donal,
>
> At least one of the TODOs (the one with the thread init) is not a 
> pressing issue, as mysql_init() will also
> call  mysql_thread_init(), according to the manual. I am not sure 
> whether it is called more than one though.
> (I think that each new connection will call mysql_init()).
>
> In my code, the connection creation (or the connection close) is not 
> protected by a mutex. I will try to change this and see what happens.
>

I'm embarrassed - because tdbc::mysql has been out so long, and I never 
fixed this. (I seem to recall that someone else volunteered, and then 
never produced any code.)

What would be needed to make it thread-safe, and I don't think there's 
any less intrusive alternative, would be:

(1) Reorganize the initialization to link to libmysqlclient_r instead of 
libmysqlclient. The last time I took a run at that, it was not obvious 
that the thread-safe library exists on all the platforms, and I didn't 
have time to chase it at the time. (Now that I take a quick look at 
stackoverflow, it appears that MySQL 5.5 and beyond have made 
re-entrancy the default, and the _r version is a symlink to the version 
without the _r. I hope that's the case. I think I needed to worry more 
about compatibility with earlier versions when the code was first deployed.)

(2) Some of the libmysqlclient_r routines have different API's, and that 
will have to be adjusted in the code. I no longer recall details. I'd 
need to read up on it again. Once again, newer MySQL's may well have 
cleaned that up.

(3) Tdbcmysql_Init will have to call mysql_thread_init if it's the first 
initialization call in any given thread.

(4) The count of interps using MySQL in any given thread will have to be 
tracked in a TSD variable, because DeletePerInterpData will have to call 
mysql_thread_end when the last interpreter in a given thread goes away. 
Letting the library call mysql_thread_init by default and ignoring 
mysql_thread_end will result in resource leaks. (Also, I don't think 
that the default actually works in a multithreaded application - it's 
set up so that legacy single-threaded code doesn't need to upgrade to do 
the thread initialization.)

I vaguely recall at the time that I was struggling with unclear 
documentation as well as platform issues (does libmysqlclient_r even 
exist everywhere?), and that the mysql mailing list/IRC forum were 
singularly unhelpful - apparently I'm not cool enough to deserve a reply 
about such questions.

I'm no longer really tooled up to test this stuff. I don't have a 
Windows machine at home any more, and I'm pretty careful to keep a 
Chinese Wall between Tcl and GE, for several bad but inescapable 
reasons. I could probably work up a patch, but it would be Unix-only 
until someone else volunteered to port and test it - or to help set me 
up with a virtualized Windows if such a thing is possible.

If I've given enough information that someone else could volunteer to 
give this a go, that would be ideal. I've been horribly time-crunched 
for most of this year. Some of that looks, Deo volente, to be easing up 
- my daughter is now safely installed in her first apartment in a 
different city, and neither my wife nor I anticipate any more surgery in 
the immediate future (my wife had her second eye done on Thursday), but 
I have a lot of catching up to do on various other projects.

-- 
73 de ke9tv/2, Kevin