List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:November 2 2005 7:09pm
Subject:Re: mysql++ connection/resuse destructor bug
View as plain text  
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.
Thread
mysql++ connection/resuse destructor bugDavid Wojtowicz1 Nov
  • Re: mysql++ connection/resuse destructor bugChris Frey1 Nov
    • RE: mysql++ connection/resuse destructor bugDavid Wojtowicz2 Nov
      • Re: mysql++ connection/resuse destructor bugChris Frey2 Nov
      • Re: mysql++ connection/resuse destructor bugChris Frey2 Nov
        • Re: mysql++ connection/resuse destructor bugWarren Young2 Nov
      • Re: mysql++ connection/resuse destructor bugWarren Young2 Nov