From owner-freebsd-arch@FreeBSD.ORG Mon Jul 7 15:12:43 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 228A31065676 for ; Mon, 7 Jul 2008 15:12:43 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.freebsd.org (Postfix) with ESMTP id 022548FC29 for ; Mon, 7 Jul 2008 15:12:43 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms074.mailsrvcs.net ([172.18.12.133]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K3N00CU868T8LA0@vms046.mailsrvcs.net> for arch@freebsd.org; Mon, 07 Jul 2008 10:12:29 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms074.mailsrvcs.net (Verizon Webmail) with HTTP; Mon, 07 Jul 2008 10:12:29 -0500 (CDT) Date: Mon, 07 Jul 2008 10:12:29 -0500 (CDT) From: Sergey Babkin X-Originating-IP: [65.242.108.162] To: Sergey Babkin , Poul-Henning Kamp Message-id: <1878557.67061215443549669.JavaMail.root@vms074.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit Cc: arch@freebsd.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2008 15:12:43 -0000 >>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. -SB