[9fans] QLocks after fork

[9fans] QLocks after fork

[Joel Salomon]

Is there some way, short of reinventing the wheel, to use QLocks to protect memory aquired by segattach(2) after a fork?

This came up when I was cribbing QLock code for user-level queued counting semaphores for homework; the professor wanted semaphores protecting a FIFO in a shared memory segment.  I was reinventing the wheel anyway, so I included a sqlistinit() function that segattached an area for the wait queue—but is there a better solution?  (Besides sharing all memory via rfork, I mean.)

--Joel

Re: [9fans] QLocks after fork

[Russ Cox]

> Is there some way, short of reinventing the wheel,
> to use QLocks to protect memory aquired by segattach(2) after a fork?

I assume you mean that you segattach and then fork,
so that you have a segment shared between both
parent and child.

Probably the easiest thing to do in this case
would be to add a function that could register
a different region of memory to hold the QLp array
in qlock.c.

Russ

Re: [9fans] QLocks after fork

[Joel Salomon]

> I assume you mean that you segattach and then fork,
> so that you have a segment shared between both
> parent and child.

Yes, that's the homework assignment; seems a reasonable scenario.

> Probably the easiest thing to do in this case
> would be to add a function that could register
> a different region of memory to hold the QLp array
> in qlock.c.

Approximately what I'm doing for the semaphore code; the qlplistinit
(I called it sqlistinit before) function calls segattach itself—or
maybe a better method would be to take a pointer from the user?  When
I get that working, I'll offer a patch for qlock.c.

(There's no particular general need for the Sem/sincr/sdecr/cansdecr
set, is there?)

--Joel