> -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
> > -Origin
> -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
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
> -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
> >> Network Nu
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
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: WaitForMultipleObjects/etc. In Kernel
Network Nut wrote:
I
-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
Network Nut wrote:
I was thinking
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
-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
-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
> -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
-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 looking at POSIX because it allows naming
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
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
> -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
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
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
-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 can simulate system-global named mutex using
> 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
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
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 name
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 a
> -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 th
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
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
-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 think that the facility by which a thread can
26 matches
Mail list logo
