From owner-freebsd-hackers@FreeBSD.ORG  Tue Nov  4 01:11:34 2003
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id DEDD016A4CF; Tue,  4 Nov 2003 01:11:34 -0800 (PST)
Received: from turtle.freedns.us (netblock-66-159-221-76.dslextreme.com
	[66.159.221.76])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 5498943FE5; Tue,  4 Nov 2003 01:11:33 -0800 (PST)
	(envelope-from bt@turtle.freedns.us)
Received: from turtle.freedns.us (localhost [127.0.0.1])
	by turtle.freedns.us (8.12.9p2/8.12.3) with ESMTP id hA49BVq3000289;
	Tue, 4 Nov 2003 01:11:31 -0800 (PST)
	(envelope-from bt@turtle.freedns.us)
Message-ID: <3FA76D43.1040508@turtle.freedns.us>
Date: Tue, 04 Nov 2003 01:11:31 -0800
From: Igor Serikov <bt@turtle.freedns.us>
Organization: Private Person
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20030209
X-Accept-Language: ru, en
MIME-Version: 1.0
To: David Schultz <das@FreeBSD.ORG>
References: <3FA61A17.70605@turtle.freedns.us>
	<20031104081800.GA78439@VARK.homeunix.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
cc: FreeBSD Hackers <freebsd-hackers@FreeBSD.ORG>
cc: FreeBSD Bugs <freebsd-bugs@FreeBSD.ORG>
Subject: Re: rfork problem
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Nov 2003 09:11:35 -0000


   David,

Is it okay to have a condition that can be created by a mortal user and 
then cannot be changed by the root? The waiting process cannot be killed 
and would keep "waiting" till system reboot.

I do not think it is a good idea to make ppwait state uninterruptible in 
any case.

As to RFNOWAIT, I believe that the correct behavior is to detach after 
leaving ppwait.


David Schultz wrote:
> On Mon, Nov 03, 2003, Igor Serikov wrote:
> 
>>  Hello,
>>
>>Combining flags RFNOWAIT and RFPPWAIT in rfork(2) under 4.6-RELEASE 
>>makes the parent process sleeping on channel "ppwait" forever.
> 
> 
> RFPPWAIT tells rfork() to wait for the child to exit, and RFNOWAIT
> tells rfork() to detach the child such that it never tells the
> parent when it exits.  So you're getting exactly what you asked
> for, as silly as it may be.
> 
>