This was many years ago (when my now-white beard was still merely grey).
Not worth going back to reconstruct the arguments, but I'll send Giacomo
and Nemo a copy of my proc.c to examine for themselves.
I'd also be interested by your copy if proc.c.
Thanks.
--
David du Colombier
I'm not convinced that I recall not being convinced ... :)
Essentially I changed the order of lock acquire/release so that the
canlock() loop in proc.c:/^postnote could be eliminated. Not significant
for performance, but it seemed more elegant and I think it also avoided
looking at any shared dat
do you remember the proposal?
thanks
> El 24 jul 2017, a las 18:39, Erik Quanstrom escribió:
>
> I had a discussion with Richard about this a few years ago. Richard was no
> longer convinced of the solution. at the time I agreed with his reasoning.
> the comment should be changed.
>
> - er
I had a discussion with Richard about this a few years ago. Richard was no longer convinced of the solution. at the time I agreed with his reasoning. the comment should be changed.- erikOn Jul 24, 2017 9:03 AM, Giacomo Tesio wrote:In /sys/src/9/port/proc.c a comment state:/** Expects that only
In /sys/src/9/port/proc.c a comment state:
/*
* Expects that only one process can call wakeup for any given Rendez.
* We hold both locks to ensure that r->p and p->r remain consistent.
* Richard Miller has a better solution that doesn't require both to
* be held simultaneously, but I'm a paranoid