Chris Frey wrote:
>
> Overall, I believe this unlock() call is just a safety / sanity check.
> It should be removed.
No, it's a half-assed attempt at enforcing the MySQL C API's
restrictions on the use of connections:
http://dev.mysql.com/doc/mysql/en/threaded-clients.html
Proper locking is necessary in the face of threads. Right now, you must
handle this explicitly in your own code, but there's no good reason why
MySQL++ can't handle this internally. When we add proper mutex support
in v2.1, the Lockable feature will pull its own weight.
> The only use of the lock mechanism in ResUse is to unlock. This goes against
> the idea that lock/unlock combos should be close together in the code, and
> always paired.
>
> I've removed it in SVN.
I'm okay with your reasoning to remove the ResUse unlock call. I don't
know for certain why it was there. Perhaps we are missing something,
and will end up with a deadlock when we get start using real mutexes in
multithreaded programs.
