Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Apr 2005 14:39:51 +0100
From:      Bruce M Simpson <bms@spc.org>
To:        Mayank Kumar <mayank@microsoft.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Query regarding thread safety of few libc stdio functions
Message-ID:  <20050425133951.GC769@empiric.icir.org>
In-Reply-To: <3A5384BC2FBA4C488865F2275A036BFF027C1614@APS-MSG-01.southpacific.corp.microsoft.com>
References:  <3A5384BC2FBA4C488865F2275A036BFF027C1614@APS-MSG-01.southpacific.corp.microsoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--VrqPEDrXMn8OVzN4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

On Mon, Apr 25, 2005 at 09:19:12PM +0800, Mayank Kumar wrote:
> Why is the same case not followed for eg with vsnprintf or vsprintf
> Vsnprintf calls directly __vfprintf which is not thread safe. Hence
> How is there thready safey guranteed. Any help on this front
> Would be helpful.

1) Thread safety/locking for the destination buffer is the calling program's
   responsibility -- the vsprintf() function could have no knowledge of this
   anyway.

2) In any event __vfprintf() references a file handle. For the vsprintf()
   case it looks like this is faked up. File handles are global, again,
   thread safety for C library file handles hasn't been specified by many
   iterations of the relevant standards (don't quote me on this, though,
   I'm no standards guru).

3) The __vfprintf() function doesn't appear to modify global data or use
   any data other than what's in its own scope. Whilst two variables are
   declared static it doesn't look like they are overwritten.

The INITEXTRA() macro appears to iniitalize the pthread mutex used by the
library functions to a default value. In any event the mutex should be
unnecessary because of 1) above. So in short I think it's thread safe
as long as your program performs the necessary locking around shared buffers,
which is not an issue which libc will solve for you anyway.

This is much the same situation as when working with MSVCRT.DLL (again,
something I've had to deal with quite a bit lately at my dayjob).

Regards,
BMS

--VrqPEDrXMn8OVzN4
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Comment: ''

iD8DBQFCbPMmueUpAYYNtTsRAqjkAKCkdvZ6uiW3UsWiUT1ZQDlLzHvcnQCfdGaw
QWiCfYmQsmtR0KSj/EIahyE=
=si/N
-----END PGP SIGNATURE-----

--VrqPEDrXMn8OVzN4--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050425133951.GC769>