Hello!

On Sun, Sep 01, 2019 at 11:45:20AM -0700, Rian Hunter wrote:

> On 2019-08-31 11:28, Maxim Dounin wrote:
> > Hello!
> >
> > On Fri, Aug 30, 2019 at 06:26:57PM -0700, Rian Hunter wrote:
> >
> >> On 2019-08-30 07:19, Maxim Dounin wrote:
> >> > Yes, this is intentional.
> >> >
> >> > The first agument of the ngx_shmtx_create() function is a pointer
> >> > to the ngx_shmtx_t structure, which is not expected to be shared
> >> > between processes. Copy of the structure as created by fork() is
> >> > enough.
> >>
> >> The POSIX sem_t member (called "sem") needs to reside in shared memory
> >> if sem_wait()/sem_post() are to have an effect across processes.
> >> Memory
> >> copied across fork is not sufficient.
> >
> > No, fork() is explicitly documented to preserve semaphores
> > (http://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html):
> >
> > : Any semaphores that are open in the parent process shall also be
> > : open in the child process.
>
> That's only true for semaphores created with sem_open(). For semaphores
> created with sem_init(pshared=1) the caller is responsible for using
> supplying memory that resides in a shared memory segment (e.g. created
> from mm ap(flags=MAP_SHARED|...)).
>
> See:
> https://blog.superpat.com/2010/07/14/semaphores-on-linux-sem_init-vs-sem_open/
>
> Here is a program that illustrates my point (also here:
> https://gist.github.com/rianhunter/a0bd4c9e8ab550ecadbe2464995726a8):

[...]

My bad, you are right here.

This isn't a problem though, as accept mutex does not use
sem_wait(), but only uses ngx_shmtx_trylock() - that is, only
atomic operations.

And for other mutexes we allocate ngx_shmtx_t structures from
shared memory, so it works fine.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel