This is the mail archive of the libc-alpha@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]

Re: Thread-, Signal- and Cancellation-safety documentation


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


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