From owner-freebsd-arch@FreeBSD.ORG Mon Jul 7 15:05:39 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 B5F85106564A; Mon, 7 Jul 2008 15:05:39 +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 952E88FC15; Mon, 7 Jul 2008 15:05:39 +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 <0K3N00DBY5WPMVKD@vms046.mailsrvcs.net>; Mon, 07 Jul 2008 10:05:14 -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:05:13 -0500 (CDT) Date: Mon, 07 Jul 2008 10:05:13 -0500 (CDT) From: Sergey Babkin X-Originating-IP: [65.242.108.162] To: Sergey Babkin , Robert Watson Message-id: <7100389.65001215443113960.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:05:39 -0000 >On Sun, 6 Jul 2008, Sergey Babkin wrote: > >> int revoke(int fd, int flags) > >Seems like that conflicts with our existing revoke(2) system call. You could Aha, I guess when I've checked, I've looked at a real old version of FreeBSD. Sure, the name can be changed. >achieve something of the same end by opening /dev/null and then dup2()'ing to >the file descriptor you want to revoke, perhaps? Right now there's a known That's a great idea. I haven't thought about it. It should do everything. >issue that calling close(2) on a socket from one thread doesn't interrupt a >socket in a blocking I/O call from another thread -- you first have to call >shutdown(2), and then close(2). This has caused problems for Java in the >past, but I'm not sure that it's really a bug given that it's not unreasonable >behavior not rejected by the spec :-). Maybe I'll see if I can fix that. -SB