This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/2745] mutex with ERRORCHECK attribute fails to unlock on child after fork
- From: "rdabrowa at poczta dot onet dot pl" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 10 Jun 2006 18:44:45 -0000
- Subject: [Bug nptl/2745] mutex with ERRORCHECK attribute fails to unlock on child after fork
- References: <20060609191820.2745.rdabrowa@poczta.onet.pl>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From rdabrowa at poczta dot onet dot pl 2006-06-10 18:44 -------
"If a multi-threaded process calls fork(), the new process shall contain a
replica of the calling thread and its entire address space, possibly including
the states of mutexes and other resources. Consequently, to avoid errors, the
child process may only execute async-signal-safe operations until such time as
one of the exec functions is called"
This is about multi-threaded processes only. Process in my example program is
single-threaded. So async-safety does not apply.
Also, do you understand "replica of the calling thread and its entire address
space, possibly including the states of mutexes and other resources" ? If the
thread owns mutex in parent process, it should own the mutex in child, too.
I think this may not apply to mutexes with PTHREAD_PROCESS_SHARED attribute,
although the standard does not say about this.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
http://sourceware.org/bugzilla/show_bug.cgi?id=2745
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.