 | | | -none- | -none- 2007-08-16 - By Warren Young
Back
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.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsub=mysql@(protected)
|
|
|