List:MySQL++« Previous MessageNext Message »
From:Chris Frey Date:November 2 2005 3:44am
Subject:Re: mysql++ connection/resuse destructor bug
View as plain text  
On Tue, Nov 01, 2005 at 07:05:20PM -0600, David Wojtowicz wrote:
>  1) If ResUse::~ResUse() didn't need to call conn_->unlock(), the problem
> would be solved.  I admit I'm not familiar enough with the internals to know
> why it is needed and there probably is a very good reason, though I can't
> easily see what it is.  I tried commenting it out and recompiling and
> running some of my programs with it and didn't run into problems.  Nothing
> else calls unlock in result.cpp, and there's no guarantee when ResUse will
> be destructed, so it doesn't seem to be important for continuing onto the
> next transaction.  But again, I'm probably missing something.

Overall, I believe this unlock() call is just a safety / sanity check.
It should be removed.  The idea that a lock()/unlock() spans two classes --
Query and ResUse -- seems wrong to me.

See line 481 in query.cpp.  This is where the lock() could happen, and
all unlock() paths appear to be covered.

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.

- Chris

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