> -----Original Message----- > From: Network Nut [mailto:sillyst...@gmail.com] > Sent: Friday, January 31, 2014 5:00 PM > To: 'Clemens Ladisch' > Cc: 'Austin S. Hemmelgarn'; linux-kernel@vger.kernel.org > Subject: RE: WaitForMultipleObjects/etc. In Kernel > > -----Original Message----- > > From: Clemens Ladisch [mailto:clem...@ladisch.de] > > Sent: Friday, January 31, 2014 4:54 PM > > To: Network Nut > > Cc: 'Austin S. Hemmelgarn'; linux-kernel@vger.kernel.org > > Subject: Re: WaitForMultipleObjects/etc. In Kernel > > > > Network Nut wrote: > > >> Assuming that you're porting to mainline distributions (and not > > >> embedded devices), named SHM segments are accessible (providing > the > > >> accessing process has correct permissions) under /dev/shm. You > > >> just need to make sure that you create the segment with the right > > >> permissions for the other processes to access it. > > > > > > I already know how to do named shared memory between two > processes. > > I only included that to describe my overall problem. > > > > > > The problem that I am having is how I can make three > > > totally-independent > > processes interact: > > > > > > 1. M is a master process that creates a semaphore. > > > 2. P1 is a process that operates against the semaphore. > > > 3. P2 is a process that operates against the semaphore. > > > 4. It is not permissible that M be responsible for launching P1 or P2. > > > 5. The semaphore, one way or another, must allow itself to be > > > specified as one of the synchronization primitives in epoll_wait() > > > > This general problem descripton does not say anything more than your > > first mail. > > > > Use eventfd. To share it, use a Unix domain socket created by M. > > (This socket must be created at a well-known path. shm_open() works > > similarly, but that it creates a file in a RAM disk and mmap()s it is > > just an implementation detail.) > > How do I create the socket at "well-known path"?
Nevermind. I see it. It is the sockaddr_un.sun_path. Thanks! -Nut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
