[freetds] tdsdump SIGSEGV with mt apps
freddyz77 at tin.it
Fri Apr 15 11:49:44 EDT 2005
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
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
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...
More information about the FreeTDS