On Tuesday 16 June 2009 10:00:49 am Bruce Simpson wrote:
Vlad Galu wrote:
...
Thanks, Ivan. I'll take a better look at this after our first release,
which is due in a couple of weeks. Right now the team efforts aren't
focused on portability, so it's a low priority issue, but something
Vlad Galu wrote:
...
Thanks, Ivan. I'll take a better look at this after our first release,
which is due in a couple of weeks. Right now the team efforts aren't
focused on portability, so it's a low priority issue, but something
we'd definitely like to have in the future.
I've just run head
On Mon, Jun 8, 2009 at 3:57 PM, Ivan Vorasivo...@freebsd.org wrote:
On a completely unrelated subject I was reading about PHP APC cache
where they have the same need - cross-process locking with locks
embedded in data structures and they have adopted userland spinlock code
from PostgreSQL:
Vlad Galu wrote:
...
Thanks, Ivan. I'll take a better look at this after our first release,
which is due in a couple of weeks. Right now the team efforts aren't
focused on portability, so it's a low priority issue, but something
we'd definitely like to have in the future.
I stand corrected.
John Baldwin wrote:
On Monday 01 June 2009 5:17:48 pm Bruce Simpson wrote:
Jilles Tjoelker wrote:
If process-shared semaphores really work, then the above structure is
not a pathological case. Effectively, sem_t is carved in stone. So
process-private semaphores should continue to have most of
On Tue, Jun 2, 2009 at 12:30 AM, Daniel Eischen deisc...@freebsd.org wrote:
[...]
Thank you all for your swift replies. It seems to indeed work for
forked processes. The app at $work (written on and for Linux)
transported an unnamed semaphore over a POSIX shared memory object.
I'll probably make
On Monday 01 June 2009 5:17:48 pm Bruce Simpson wrote:
Jilles Tjoelker wrote:
If process-shared semaphores really work, then the above structure is
not a pathological case. Effectively, sem_t is carved in stone. So
process-private semaphores should continue to have most of their stuff
in
Hello,
According to sem_init(3), we can't have shared unnamed semaphores.
However, the following code snippet seems to work just fine:
-- cut here --
sem_t semaphore;
if (sem_init(semaphore, 1, 10) 0)
std::cout Couldn't init semaphore:
strerror(errno)
On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote:
Hello,
According to sem_init(3), we can't have shared unnamed semaphores.
However, the following code snippet seems to work just fine:
-- cut here --
sem_t semaphore;
if (sem_init(semaphore, 1, 10) 0)
On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote:
According to sem_init(3), we can't have shared unnamed semaphores.
However, the following code snippet seems to work just fine:
-- cut here --
sem_t semaphore;
if (sem_init(semaphore, 1, 10) 0)
Jilles Tjoelker wrote:
If process-shared semaphores really work, then the above structure is
not a pathological case. Effectively, sem_t is carved in stone. So
process-private semaphores should continue to have most of their stuff
in a separately allocated structure, to preserve flexibility.
On Mon, 1 Jun 2009, Bruce Simpson wrote:
Jilles Tjoelker wrote:
If process-shared semaphores really work, then the above structure is
not a pathological case. Effectively, sem_t is carved in stone. So
process-private semaphores should continue to have most of their stuff
in a separately
12 matches
Mail list logo
