Re: libct ct_connect thread_safe

On Wed, 14 Dec 2011 16:18:23 -0700
Mitch Freed <[email protected]> wrote:

> Is ct_connect (libct) not thread-safe? 
...
> I have seen the FAQ indicating that the threads cannot share a 
> CS_CONNECTION, which they do not in my case.

I don't understand those two statements.  ct_connect() takes a
CS_CONNECTION* as its first argument.  "Cannot share a connection"
means cannot use a single CS_CONNECTION struct in more than one
thread.  Calling ct_connect() *is* using that connection.  

So, no, I guess you'd have to say ct_connect() is not thread-safe.  Not
that it should be, either!  

I would be curious to know (from anyone) why you use
more than one thread to interact with a server connection.  The server
is I/O bound by the network.  The client is certainly faster or, if not,
two threads won't be faster than one.  

The only answer I know of is when the client is some kind of
multithreaded something (a webserver, say) sharing a smaller number
of database connections.  

But why?  In the vast majority of cases, that is a false economy: the
overhead of making connections and of the server supporting 1:1
connections/thread is negligible.  How do I know?  Because the vast
majority of websites are small and slow.  

Unless you're measuring response times in milliseconds, what
difference can the time it takes to connect to the server possibly
make?  As soon as you accept the connect-time overhead, you know that
every connection is needed, and that therefore if the database server
can't support those connections, you need one that can.  (Probably you
need more RAM.)  

Maybe you're reading this, saying to yourself that you can't wait for
the time it takes to log in.  If so, I'd like to understand why not.
Really.  I know sites like Google have scale and throughput issues that
require sophistication.  But I also know most sites aren't a big as
Google.  

My test database server is ~300 ms away, round trip, says ping.  
time(1) reports I can ping it 100 times in ~50 seconds (using a loop in
bash).  That same loop lets me log in 100 times in ~60 seconds using
tsql.  That puts each ping, allowing bash overhead, etc., at 500 ms,
and each login at 600 ms, or 100 ms to log in.  That's consistent with
my experience at work; I've never used a server where login times were
significant.  Or a webserver with latency in that neighborhood,
either, for that matter.  

What am I overlooking?  I'd bet 9 in 10 webservers not using 1:1
database connections are wasting time engineering something that
doesn't need engineering. Would someone please tell Mitt Romney?  I
hear tell he's a betting man.  

--jkl