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
