From owner-freebsd-arch@FreeBSD.ORG  Mon Jul  7 18:52:34 2008
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 A9997106567B
	for <arch@FreeBSD.ORG>; Mon,  7 Jul 2008 18:52:34 +0000 (UTC)
	(envelope-from das@FreeBSD.ORG)
Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101])
	by mx1.freebsd.org (Postfix) with ESMTP id 68FA08FC17
	for <arch@FreeBSD.ORG>; Mon,  7 Jul 2008 18:52:34 +0000 (UTC)
	(envelope-from das@FreeBSD.ORG)
Received: from zim.MIT.EDU (localhost [127.0.0.1])
	by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m67IN2pL034901;
	Mon, 7 Jul 2008 14:23:02 -0400 (EDT) (envelope-from das@FreeBSD.ORG)
Received: (from das@localhost)
	by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m67IN29O034900;
	Mon, 7 Jul 2008 14:23:02 -0400 (EDT) (envelope-from das@FreeBSD.ORG)
Date: Mon, 7 Jul 2008 14:23:02 -0400
From: David Schultz <das@FreeBSD.ORG>
To: Sergey Babkin <babkin@verizon.net>
Message-ID: <20080707182302.GA34751@zim.MIT.EDU>
Mail-Followup-To: Sergey Babkin <babkin@verizon.net>,
	Poul-Henning Kamp <phk@phk.freebsd.dk>, arch@FreeBSD.ORG
References: <1878557.67061215443549669.JavaMail.root@vms074.mailsrvcs.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1878557.67061215443549669.JavaMail.root@vms074.mailsrvcs.net>
Cc: arch@FreeBSD.ORG, Poul-Henning Kamp <phk@phk.freebsd.dk>
Subject: Re: 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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jul 2008 18:52:34 -0000

On Mon, Jul 07, 2008, Sergey Babkin wrote:
> >>Rationale:
> >>
> >>In the multithreaded programs often multiple threads work with the
> >>same file descriptor. A particularly typical situation is a reader
> >>thread and a writer thread. The reader thread calls read(), gets
> >>blocked until it gets more data, then processes the data and
> >>continues the loop. Another example of a "reader thread" would be 
> >>the main thread of a daemon that accepts the incoming connections
> >>and starts new per-connection threads. 
> >
> >Have you tried to implement the functionality you're asking for ?
> >
> >You'll have to hunt down into all sorts of protocols, drivers
> >and other code to find the threads sleeping on your fd so you can
> >wake them.
> 
> 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.

In Solaris, if you close a file descriptor that has blocked
readers, the readers wake up and read() returns 0 bytes (EOF).
(At least this is true if you close the local end of a pipe.)
It seems like implementing the same behavior in FreeBSD would
address your problem without introducing a new system call.
Is there a good reason why this might not be the right thing to do?