Skip to Content.
Sympa Menu

freetds - RE: asprintf vasprintf

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Brian Bruns" <camber AT ais.org>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: RE: asprintf vasprintf
  • Date: Thu, 29 Aug 2002 13:14:03 -0400


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




Archive powered by MHonArc 2.6.24.

Top of Page