Skip to Content.
Sympa Menu

freetds - RE: [freetds] dblib and thread safety

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] dblib and thread safety
  • Date: Mon, 20 Sep 2004 17:24:31 +0200

>
> On Tue, Sep 14, 2004 at 04:05:38PM +0200, ZIGLIO, Frediano,
> VF-IT wrote:
>
> > I think you are right. Do you know a small and portable
> library to do
> > this job (using mutex) ??
>
> Well, for POSIX hosts, POSIX 1003.1c threads is the right
> answer. For Win32,
> another set of ifdefs that add critical sections would be
> fine. However,
> as I'm not a Win32 person, I can't code/test this.
>
> Please find attached my patch to the latest CVS snapshot for dblib.c.
> I've done some functional and load tests on Solaris and Linux and so
> far, so good.
>
> Appreciate it if you could apply it to CVS.
>
> Cheers,
> Liam
>

I'd like too... this patch have however some problems:
1- portability
2- tds context lock

1- pthread.h it's not that portable, configure script and perhaps some
macros/functions are needed
2- you use lock for tds_ctx however I don't know if this it's a good
idea. Context it's used in libTDS only for read informations (I checked
this in all libTDS source)... you lock entire dblib for too long and you
have also to consided that a pointer to context it's stored in TDSSOCKET
structure so you should lock every libTDS call (a good way to make dblib
a monothread library... not that fine...). I looker even in dblib code
and context are allocated and initialized in dbinit and uninitialized
and freed in dbexit so this seems not a problem... just don't use lock
if you use tds_ctx.

So I would define some functions/macros and configure to handle case 1
and rewrite some part of patch for case 2.

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page