atomic Xprintf

[Brian Ford]

On Wed, 26 May 2004, Jeff Johnston wrote:

> Jeff Johnston wrote:
> > Brian Ford wrote:
> >> This Cygwin bug:
> >>
> >> http://www.cygwin.com/ml/cygwin/2004-05/msg00765.html
> >>
> >> appears to be caused by these changes:
> >>
> >> 2003-08-22  Jeff Johnston  <jjohnstn at redhat dot com>
> >>
> >>         * libc/stdio/vasprintf.c: Ditto.  Also call _vfprintf_r directly.
> >>         * libc/stdio/vsnprintf.c: Ditto.
> >>         * libc/stdio/vsprintf.c: Ditto.
> >>         * libc/stdio/snprintf.c: Call _vfprintf_r directly.
> >>         * libc/stdio/sprintf.c: Ditto.
> >>         * libc/stdio/vprintf.c: Ditto.  Also add _REENT_ONLY check.
> >>
> >> Calling _vfprintf_r directly avoids the f[lock|unlock]file calls that
> >> would happen if just _vfprintf were called.
> >>
> >> I don't understand the reasoning for this change.  Could someone please
> >> explain?  Thanks.
> >
> > It was a case of eliminating an extraneous call as the _r routines in
> > the same files call _vfprintf_r directly.  It was obviously an oversight
> > on my part regarding the locking aspsect, however, it is equally
> > obvious, the locking is being performed in the wrong place.  While the
> > old call handled the locking for the regular I/O printf functions, the
> > fact remains that the _r versions of _vasprintf_r, etc.. all call
> > _vfprintf_r directly and they are not protected. Pushing the locking
> > down into _vfprintf_r should fix the problems.
>
> Brian,
>
>    Can you try out the attached patch and verify if it solves the problem?

Yes, this looks good.  Please apply, and thanks.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...