FreeTDS Development Group

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

> > 
> > 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.
> 

Does this patch works (and sound ok) ??

freddy77

Attachment: pthread.diff.gz
Description: pthread.diff.gz