On Mon, Aug 28, 2000 at 08:12:45AM -0400, Bill Sommerfeld wrote:
> This logic is fallacious.  Syscall functions take a proc "p" as their
> third argument; however, they're not necessarily going to work
> correctly if p != curproc.  On smp systems, evaluating "curproc" may
> be expensive; bsd4.4 started passing curproc around explicitly in the
> in-kernel interfaces.  This is no different.

Ok, so the question remain: does fork1() currently work for p1 != curproc ?
If not then the check for P_HOLD can go away.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--