Skip to Content.
Sympa Menu

freetds - Re: [freetds] tdsdump SIGSEGV with mt apps

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] tdsdump SIGSEGV with mt apps
  • Date: Fri, 15 Apr 2005 17:49:44 +0200

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






Archive powered by MHonArc 2.6.24.

Top of Page