FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il giorno ven, 15-04-2005 alle 18:31 +1000, liam AT inodes.org ha scritto:
> On Wed, Apr 13, 2005 at 05:01:03PM +0200, ZIGLIO, Frediano, VF-IT wrote:
> 
> > Please work on 0.64. Many thing has changed in cancel/timeout stuff. Is
> > more easier to improve thread safety in 0.64.
> 
> In terms of thread saftey for logging, it is most likely easiest to
> add a mutex and ensure that the logging functions acquire and release 
> the mutex when performing various operations.
> 

I think so, it can be a performance bottleneck but how care for
performance while logging debugging information??

> More importantly, I want to discuss dblib thread saftey. 
> 
> My previous patch placed a mutex around DBLIBCONTEXT.
> 
> Is there any reason why this the data in DBLIBCONTEXT can't be carried 
> inside DBPROCESS and LOGINREC? This would by default make dblib mostly
> thread-safe. I don't see the point of putting a connection list 
> inside DBLIBCONTEXT, etc.
> 

I would use mutex for connection list/recftos members.

Well, TDSCONTEXT it's global in dblib so this was the reason to put it
global. It contains three classes of informations:
1- pointer to parent (witch in dblib is constant cause dblib context is
global)
2- locale information
3- error handling function (always constant)
Adding a TDSCONTEXT member to DBPROCESS seems a solution however is
locale information global? Is there a way in dblib to change locale
informations? I constify a bit TDSCONTEXT in libTDS and I can say that
TDSCONTEXT is never changed in all libTDS... Honestly I don't understand
which threadsafe problem have TDSCONTEXT in dblib...

> Anything that needs to be shared amongst connections (e.g configuration
> information and timeouts) can be placed in a global structure and
> protected by a mutex.
> 

I agree, but easy mutex coding can be a very performance bottleneck...

> If the TDSCONTEXT itself is by definition of its implementation not 
> thread safe, then it might best be left there and protected by a 
> mutex.
> 

By definition of its implementation... what does it mean??

> Also Frediano, do you still want to push for the abstraction of 
> POSIX thread functions for portability?
> 

Yes, I don't think that FreeTDS need too much mutex function and also
windows still don't have posix thread function...

freddy77