FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

Ok, think i got it.  Somebody mentioned something about a mutex, so I was
unsure.  I did the original vsnprintf implementation which i stole from
the man page.  Is the primary problem here speed of the multiple reallocs
or some reentrancy problem?

Brian

> > From: Brian Bruns [mailto:camber AT ais.org]
> > Sent: August 29, 2002 12:42 PM
> >
> > can someone give me a quick summary on this?  
> 
> OK, but quick isn't my forte. :)
> 
> > I'd rather not have any thread primitives in the
> > library if we can avoid it even if it does mean implementing 
> > our own on
> > those platforms that don't have a suitable reentrant function. 
> 
> No one's added any threading code per se that I know of.  
> 
> > And if we
> > have suitable functions on different platforms (Tru64 has X, 
> > linux has Y, HP/UX has Z) can we wrap them and use autoconf to test?
> 
> That's what we do.
> 
> Basically, there was one call to vsnprintf(); it supported dbfcmd().  Nick
> looked at it, decided what was really needed was vasprintf().  He sent it in
> as PD.  I added it, wrapping the body of the .c in #if !HAVE_VASPRINTF, so
> the module is effectively empty if the OS provides an implementation.  
> 
> Nick's implementation relied on writing to a too-small buffer, trapping
> SIGSEGV, extending the buffer as needed.  Works single threaded, very nice,
> a joy to behold.  Multithreaded, though, could cause a problem because of a
> race condition:
> 
> 1.    enter vasprintf.
> 2.    install signal handler, prepare to write to buffer.
> 3.    other thread faults.
> 4.    vasprintf handler does something stupid.
> 5.    bad things happen. 
> 
> Nick's long mail details why there's no good way for a library to deal with
> signal handling in threaded environments.  So goes the war.  He is
> re-implementing the function such that it doesn't rely on signals.  
> 
> --jkl