FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> > I've double-checked your patch and I've made a few modifications to 
> 
> Sorry, the patch I originaly sent has a dead-lock in 
> dbexit(). Please see 
> attached the corrected one.
> 
> Thanks.
> 

I see. However tds_ctx it's referenced in TDSSOCKET and used (only for
reading) in all libTDS functions. So you have active readed structures
while you have connections. If you call dbexit dblib free all
connections so you "release" all pointers and you can safely delete
context. In dbinit you allocate context so only dbinit can write to this
context, it's not useful to initialize context inside the mutex. Perhaps
we should check for no connections inside dbinit. It's an error to call
dbinit after another dbinit. It's also a programmer error to call dbinit
while another dblib function it's called... I used no recursive mutex
cause are faster and cause my code don't need recursive one (if we
require recursive one I have to change configure too). tds_convert use
context (it use locale informations to convert to/from date).

Consider this code

 int
 dbgetmaxprocs(void)
 {
-       return g_dblib_ctx.connection_list_size_represented;
+       int c;
+       dblib_mutex_lock();
+       c = g_dblib_ctx.connection_list_size_represented;
+       dblib_mutex_unlock();
+       return c;
 }

every processor I know can read memory in a single instruction. It's not
useful to use mutex here. Better to use volatile to disallow strange
optmizations.

For full thread safe for context you have to prevent a thread inside a
dblib call and call to dbexit... however I don't know a solution for
this... use a rw lock in every dblib ?

freddy77