This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/4737] fork is not async-signal-safe


http://sourceware.org/bugzilla/show_bug.cgi?id=4737

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #21 from Rich Felker <bugdal at aerifal dot cx> 2011-10-14 14:05:00 UTC ---
It should be noted that this bug, even if irrelevant to future POSIX revisions,
can easily be fixed. Either recursive or error-checking mutexes will work, but
they must also be reentrant, i.e. the mutex must be in a consistent state with
the owner and lock count correct immediately after the atomic operation to take
the lock completes successfully. This is most easily achieved by putting the
owner id in the atomic lock field and using a zero-based lock count (where the
first lock operation does not increment the count and the last unlock does not
decrement it). The only additional cost is looking up the caller's thread id,
if this is not already performed in the existing locking code... but for some
archs that may be prohibitively costly...

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]