[PATCH]: Thread safe stdio with cygwin
Thu Jan 15 16:38:00 GMT 2004
Thomas Pfaff wrote:
> memset makes only sure that _lock does not contain random data before
> __lock_init_recursive. __lock_init_recursive is called later when the
> file is really opened.
I assumed you were worried about something accessing the file pointer
before fopen/freopen returned the file pointer so it would then make
sense just to initialize it earlier. Otherwise, the
__lock_init_recursive should initialize the lock without need for
> __sbprintf is a special case because it generates a fake FILE pointer
> and its associated buf on the stack, therefore there is no need to
> lock it fo thread safety.
There may be no need to lock, but the VFPRINTF code attempts a lock and
unlock anyway. It then makes sense to ensure that the lock is validly
initialized/closed for any platform's lock implementation.
-- Jeff J.
> Jeff Johnston wrote:
>> You should be using __lock_init_recursive to initialize the locks
>> rather than zeroing them out.
>> The code in __sbprintf should probably be closing the lock after the
>> call to VFPRINTF as well.
>> -- Jeff J.
>> Thomas Pfaff wrote:
>>> This patch adds support for thread safe stdio for Cygwin.
>>> Cygwin uses dynamic mutexes for locking, therefore it is
>>> necessary to:
>>> 1. Initialize FILE pointers _lock properly.
>>> 2. Destroy the lock when it is no longer needed.
>>> 2004-01-12 Thomas Pfaff <email@example.com>
>>> * libc/stdio/fclose.c: Include sys/lock.h.
>>> (fclose): Destroy lock when file is closed.
>>> * libc/stdio/findfp.c (__sfp): Initialize file pointers _lock
>>> * libc/stdio/freopen.c: Include sys/lock.h.
>>> (_freopen_r): Destroy lock when file is closed.
>>> * libc/stdio/vfprintf.c (__sbprintf): Initialize file pointers
>>> _lock member.
More information about the Newlib