Re: [9front] Re: commit b3a26fb633f4649fc202b77c0184184b756960e7

[cinap_lenrek@felloff.net]

> Perhaps I'm missing something but is it safe to call ready
> outside of the p->rlock?

I do not see any issue with calling ready() outside
of the p->rlock.

In sleep, we set the process state to Wakeme
only when we have both locks. From there on, we'r
committed to go to sleep and we can call ready()
on it (once).

Double ready should not happen as we clear r->p and p->r.

> I thought it was a requirement for a Rendez to be kept
> around by other means if there is a possibility that it may
> be accessed by other proc.

I do not know of any such requirements. The sleep and
wakeup paper is also silent on this topic and the bug
is also right there in the listed code.

The only requirement i know is that Proc's must never
be re-used as something other than a Proc.

> So isn't the Rendez on the stack in semacquire the actual problem?

I can see this being a issue also if the Rendez or QLock
is in dynamically allocated memory. Not just the stack.

I also dont like the Rendez on the stack and i know
we can even save some memory by just using &up->sleep
as the rendezvous point instead of embedding it the
Sema struct. But this isnt addressing the problem at hand.

> ...

> The key change is to zero r->p immediately after saving it
> to p so the critical section involving r is just:

>	lock(r)
>	p = r->p
>	r->p = nil
>	unlock(r)

Maybe, tho i wanted to address the problem at hand.

> What do you think?

I'm going back to sleep :)

--
cinap