Query regarding thread safety of few libc stdio functions
Bruce M Simpson
bms at spc.org
Mon Apr 25 06:39:59 PDT 2005
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 167 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20050425/c9d49473/attachment.bin
More information about the freebsd-current
mailing list