RE: WaitForMultipleObjects/etc. In Kernel

2014-01-31 Thread Network Nut
> -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 &

RE: WaitForMultipleObjects/etc. In Kernel

2014-01-31 Thread Network Nut
> -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 > > Net

Re: WaitForMultipleObjects/etc. In Kernel

2014-01-31 Thread Clemens Ladisch
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 permis

RE: WaitForMultipleObjects/etc. In Kernel

2014-01-31 Thread Network Nut
> -Original Message- > From: Austin S. Hemmelgarn [mailto:ahferro...@gmail.com] > Sent: Friday, January 31, 2014 11:05 AM > To: Network Nut; 'Clemens Ladisch' > Cc: linux-kernel@vger.kernel.org > Subject: Re: WaitForMultipleObjects/etc. In Kernel > >>

Re: WaitForMultipleObjects/etc. In Kernel

2014-01-31 Thread Austin S. Hemmelgarn
On 01/30/2014 06:49 PM, Network Nut wrote: >> -Original Message- >> From: Clemens Ladisch [mailto:clem...@ladisch.de] >> Sent: Wednesday, January 29, 2014 2:31 AM >> To: Network Nut >> Cc: linux-kernel@vger.kernel.org >> Subject: RE: WaitForMultiple

RE: WaitForMultipleObjects/etc. In Kernel

2014-01-30 Thread Network Nut
> -Original Message- > From: Clemens Ladisch [mailto:clem...@ladisch.de] > Sent: Wednesday, January 29, 2014 2:31 AM > To: Network Nut > Cc: linux-kernel@vger.kernel.org > Subject: RE: WaitForMultipleObjects/etc. In Kernel > > Network Nut wrote: > >I was look

RE: WaitForMultipleObjects/etc. In Kernel

2014-01-29 Thread Clemens Ladisch
Network Nut wrote: >I was looking at POSIX because it allows naming of the primitives. Linux uses two orthogonal mechanisms for synchronization primitives and for naming/sharing. >I need to epoll_wait on inter-process {mutex, event, semaphore}. Use eventfd. >I need to reference inter-process {m

RE: WaitForMultipleObjects/etc. In Kernel

2014-01-28 Thread Network Nut
> -Original Message- > From: Clemens Ladisch [mailto:clem...@ladisch.de] > Sent: Tuesday, January 28, 2014 3:04 AM > To: Network Nut > Cc: linux-kernel@vger.kernel.org > Subject: Re: WaitForMultipleObjects/etc. In Kernel > > Network Nut wrote: > > 5. I ca

Re: WaitForMultipleObjects/etc. In Kernel

2014-01-28 Thread Clemens Ladisch
Network Nut wrote: > 5. I can simulate system-global named mutex using shared-memory for > underlying state of mutex (POCO NamedMutex) > 6. I can get named semaphore using POSIX sem_create > > It seems that the remaining problem is to get named mutex and named > semaphore to be accessible by file-d

RE: WaitForMultipleObjects/etc. In Kernel

2014-01-27 Thread Network Nut
> Unrelated processes cannot directly open objects created by another > process (with the exception of sockets and pipes, which can be created in > the file system). However, sharing of any file descriptor is possible by > sending it in a control message through a Unix domain socket. I just spent

Re: WaitForMultipleObjects/etc. In Kernel

2014-01-27 Thread Clemens Ladisch
Network Nut wrote: > As you know, under Windows, synchronization objects such as {event | mutex | > semaphore | timer}; all have names that are computer-global. Process B can > open, and use, any {event | mutex | semaphore | timer} that was created by > process A, as long as Process B knows the nam

RE: WaitForMultipleObjects/etc. In Kernel

2014-01-26 Thread Network Nut
> -Original Message- > From: Clemens Ladisch [mailto:clem...@ladisch.de] > Sent: Sunday, January 26, 2014 12:33 PM > To: Network Nut > Cc: linux-kernel@vger.kernel.org > Subject: Re: WaitForMultipleObjects/etc. In Kernel > > Network Nut wrote: > > I thin

Re: WaitForMultipleObjects/etc. In Kernel

2014-01-26 Thread Clemens Ladisch
Network Nut wrote: > I think that the facility by which a thread can block while waiting for any > of several synchronization primitives (*mutex*, *semaphore*, *event*, > *waitable > timer*)...is not only "nice to have", but fundamental to complex (clean) > multi-threaded programming. You mean a

WaitForMultipleObjects/etc. In Kernel

2014-01-25 Thread Network Nut
Hi All, This is my first post to anything Linux, so if there is a better mailing list, please let me know. I think that the facility by which a thread can block while waiting for any of several synchronization primitives (*mutex*, *semaphore*, *event*, *waitable timer*)...is not only "nice to hav