Re: Eyeballs needed on new reference counted pointer template

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=lists@pantek.com

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek