forked from ryszard/clsql
-
Notifications
You must be signed in to change notification settings - Fork 12
Open
Description
Hey guys,
I spent this whole nigth banging my head trying to understand source of creepy connections errors.
They were so creepy that I started to think about multitheading issues :-). And here we go
http://dev.mysql.com/doc/refman/5.0/en/mysql-library-init.html
In a nonmulti-threaded environment, the call to mysql_library_init() may be omitted, because
mysql_init() will invoke it automatically as necessary. However, mysql_library_init() is not thread-safe
in a multi-threaded environment, and thus neither is mysql_init(), which calls mysql_library_init(). You
must either call mysql_library_init() prior to spawning any threads, or else use a mutex to protect the
call, whether you invoke mysql_library_init() or indirectly through mysql_init(). Do this prior to any other
client library call.
Test case is simple (from memory):
(loop for i from 0 to 9 do
(sb-thread:make-thread (lambda () (clsql:with-database ("" "" "" "") :database-type :mysql))))
that is it. If lucky you can see something like
2013 :MESSAGE "Lost connection to MySQL server during query"
or maybe even
Error 2013 / Lost connection to MySQL server at 'reading initial communication packet', system error: 4
Right now as a hot fix I wrapped database-connect
with mutex.
However I like mysql_library_init
way more. What you think? I'm happy to create pull request with fix but before I would like to hear what you think is the best.
Metadata
Metadata
Assignees
Labels
No labels