On 08-May-01 Seigo Tanimura wrote:
> On Mon, 07 May 2001 12:37:22 -0700 (PDT),
>   John Baldwin <[EMAIL PROTECTED]> said:
> John> You need the lock when clearing the bit in p_flag.  That is why the
> proc locks
> John> are there, so all those proc locks need to stay.  When you clear a bit,
> you are
> John> writing all the bits, so you need to ensure that you can atomically
> John> read/modify/write all the bits in p_flag, hence the need for the proc
> lock.
> John> Please back out the changes to not lock the process around the p_flag
> change. 
> John> The rest of the patch looks ok, though I'd like to review the updated
> version
> John> before it is committed.  Thanks.
> Process locks are now back.
> Here is another issue. PROC_LOCK may block to acquire a process lock,
> during which an event of interest may occur or the remaining time of
> select(2)/poll(2) may run out. Thus if the remaining time runs out
> during locking a process, we should first rescan file descriptors to
> avoid missing an event, followed by returning the result.
> Those changes are now in the updated patch at:
>>> http://people.FreeBSD.org/~tanimura/patches/selectopt.diff

Hmmm.  Actually, can the nb_poll, ncp_poll, pollscan, or selscan functions call
tsleep/msleep?  If they don't, then we are just better off holding proc lock
while we call them rather than releasing it just to call that function and
acquiring it later.  Then we don't have to work around the race you describe.

Also, in the done_noproclock: case (might want to use 'unlock:' and 'done:'
instead of 'done:' and 'done_noproclock:' for label names instead) are you
always sure that when you go to that label you don't need to clear P_SELECT?


John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to