This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: Rich Felker <dalias at aerifal dot cx>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sun, 2 Jun 2013 17:59:32 -0400
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <1368788184 dot 3054 dot 3161 dot camel at triegel dot csb> <orehd3h2j4 dot fsf at livre dot home> <1369588322 dot 16968 dot 2933 dot camel at triegel dot csb> <orip20qzua dot fsf at livre dot home> <1369936586 dot 16968 dot 9405 dot camel at triegel dot csb> <orehcmq122 dot fsf at livre dot home> <orehclih8s dot fsf at livre dot home> <ory5atgkyr dot fsf at livre dot home> <20130602143136 dot GM20323 at brightrain dot aerifal dot cx> <orppw4h1v1 dot fsf at livre dot home>
On Sun, Jun 02, 2013 at 02:13:54PM -0300, Alexandre Oliva wrote:
> > I agree with your analysis. I'm not sure whether this is intentional
> > or an oversight. I suspect many historical applications perform
> > synchronization of shared memory maps with pipes or other
> > filesystem-based methods,
>
> You speak of multiple processes here, rather than historical
> multi-threaded applications, right? Not that it makes any difference
> AFAICT and as far as the standard is concerned. I'm just trying to be
> sure I undertood correctly what apps you're speaking of.
I was thinking mainly of separate processes; however, use of the
self-pipe trick for signal handling may make the issue come into play
for multi-threaded apps too. Use of pipes for synchronization from
signal handlers is usually necessary because the normal
synchronization primitives you would want to use are not
async-signal-safe, except for sem_post.
> > and I also suspect that all historical implementations have full
> > memory barriers, not by choice but because they're inevitable, in the
> > kernelspace part of any function capable of performing inter-process
> > communication.
>
> Well, I'm not sure, even mmaped files are not guaranteed to have changes
> visible to other processes before explicit flushes by munmap or so...
> Of course there are programs designed for systems that offer actual
> shared memory, rather than a simulation without the benefit of an MMU,
> but, strictly speaking, those may already be outside conformant and
> well-defined behavior.
POSIX requires actual shared memory. An implementation that fakes it
is not conforming.
Rich