:>:
:>:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
:>
:> Huh? It doesn't look like the same algorithm to me.
:
:In exit1() we attempt to free resources early if we can. If we lose the race,
:we still clean it up in vmspace_free() called from cpu_wait(). If you check
:the shm pointer and do shmexit() in vmspace_free() just as is done in
:vmspace_free(), then you will catch any cases that fall through with the shm
:not being free'd using the same technique currently employed in releasing the
:vmspace and with a minimal amount of change to the code.
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
The whole point is to release resources as early as possible. Why would
you ever want to intentionally introduce a race that will 'sometimes' be
lost and thus cause a late resource release when you can just as easily
completely guarentee that the resource will be released early, and thus
never have to worry about it. That makes no sense at all. From the
point of view of algorithm design, it's much better to know what *will*
happen rather then what *might* happen.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
