Well, the manual page (which may be out of date) infers
that the rfork() only operates on the current process if
RFPROC is not set. If we extend that to include RFTHREAD
then the inference is that either RFPROC or RFTHREAD must be
set and if neither is set an error should be returned. Am
I missing something?
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:I think there can be a problem if we allow rfork without
:either RFCFDG or RFFDG and RFTHREAD.
:
:Basically because we cache the ADVLOCK flag in the proc
:we may have a situation where this happens:
:
:p1 rfork(RFMEM); /* gets back p2 */
:p2 advlocks some files from the shared table
:p2 exits, but since the refcount on the fdesc is still > 0 we leave it
: alone and leak lock structures.
:p1 exits
:
:Does this make sense as a problem area? I think we should only
:allow filedesc sharing if RFTHREAD is set. RFTHREAD seems to get
:it right because of the peers/leader mechanism.
:
:thanks,
:--
:-Alfred Perlstein [[EMAIL PROTECTED]]
:'Instead of asking why a piece of software is using "1970s technology,"
: start asking why software is ignoring 30 years of accumulated wisdom.'
:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
