From owner-freebsd-arch@FreeBSD.ORG Mon Jul 7 16:04:12 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D820A106568D for ; Mon, 7 Jul 2008 16:04:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4798FC1C for ; Mon, 7 Jul 2008 16:04:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.3]) by phk.freebsd.dk (Postfix) with ESMTP id 194A3170EB; Mon, 7 Jul 2008 16:04:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m67G4A47006861; Mon, 7 Jul 2008 16:04:10 GMT (envelope-from phk@critter.freebsd.dk) To: Sergey Babkin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 07 Jul 2008 10:12:29 EST." <1878557.67061215443549669.JavaMail.root@vms074.mailsrvcs.net> Date: Mon, 07 Jul 2008 16:04:10 +0000 Message-ID: <6860.1215446650@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: arch@freebsd.org Subject: Re: Proposal: a revoke() system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2008 16:04:12 -0000 In message <1878557.67061215443549669.JavaMail.root@vms074.mailsrvcs.net>, Serg ey Babkin writes: >My thinking has been that if close() wakes them up, then things would be >inherited from there. The thing I didn't know is that apparently in many cases close() >doesn't wake them up. It's a novel idea, seen with POSIX eyes, that a thread can close a fd it is sleeping on, so the semantics, how obvious they might be, is not described in the standards, and more importantly, not described in the code either. The device driver problem has more angles to it and should be thought out separately, since the same basic functionality is required for hardware removal, only more draconian. I'm not saying that such a systemcall is not a good idea, I'm merely very cautious about what it takes to implement it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.