From: Warren Young
Date: August 16 2007 8:55am
Subject: Re: Eyeballs needed on new reference counted pointer template
List-Archive: http://lists.mysql.com/plusplus/6955
Message-Id: <46C4110C.8060200@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Joseph Artsimovich wrote:
> 
> 1. It's not thread-safe.  

MySQL++ isn't thread-safe today [*], and it will never be truly 
"thread-safe" in the sense that any thread can do anything it likes at 
any time.

I don't even think it would be a good idea if it did happen.  What 
practical benefit would you really expect this to provide?  The 
bottleneck is *never* in MySQL++.  The bottleneck is the network link, 
or the transfer rate on the database server's RAID array, or the memory 
bandwidth of the server itself as it deals with a constant assault by a 
hundred other clients.  If you think you need even two concurrent 
threads issuing queries through MySQL++, you're probably wrong.

The highest aspiration I have for thread-awareness in a future MySQL++ 
is to prevent user code from running into the limits imposed by the C 
API by use of mutexes.  So for instance, if a thread tries to create a 
query on a connection that is already running a query for another 
thread, it will block the second thread until the first is done.  And 
don't tell me that this is lame; it is better than the situation today, 
in which the second thread just gets an error.  The proper thing is for 
the second thread to not even try reusing the connection, if speed or 
responsiveness matters.  If it needs to be able to issue a query without 
being blocked, it will need its own Connection no matter what I do.  At 
that point, you don't need any special thread support; that's the status 
quo today.

This does rule out the possibility of passing MySQL++ data structures 
between threads without outside synchronization.  I don't see much 
practical benefit for this.  The only one that may be at all useful is a 
ColData used for BLOB storage in an SSQLS.  All you need in that case is 
a little handshaking within your own code to manage the handoff of data 
from MySQL++ to the thread that will process it.  There's no need for 
MySQL++ to manage this itself.

[*] MySQL++ can be built against threading libraries today, and as best 
we can, we avoid using functions with internal static buffers.  (See the 
recent localtime() replacement work, for instance.)  This is the extent 
of thread awareness in MySQL++ today.  This doesn't count as "thread 
safe" by even the most liberal definition.

> 3. It should be possible to do this:
> class A {};
> class B : public A {};
> RefCountedPointer<B> pb(new B);
> RefCountedPointer<A> pa(pb);

This template is not intended to be a general purpose facility for use 
by MySQL++ client code.  It only needs to solve MySQL++'s internal 
problems.  If the limited scope of RefCountedPointer solves someone 
else's problems, too, that's great.  If not, there are many other wheels 
of this sort out there.