From owner-freebsd-arch@FreeBSD.ORG Mon Jul 7 17:33:06 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 CD14D106568F; Mon, 7 Jul 2008 17:33:06 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.freebsd.org (Postfix) with ESMTP id ACE438FC0C; Mon, 7 Jul 2008 17:33:06 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms227.mailsrvcs.net ([172.18.12.133]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K3N00B47CQO99L4@vms044.mailsrvcs.net>; Mon, 07 Jul 2008 12:32:48 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms227.mailsrvcs.net (Verizon Webmail) with HTTP; Mon, 07 Jul 2008 12:32:48 -0500 (CDT) Date: Mon, 07 Jul 2008 12:32:48 -0500 (CDT) From: Sergey Babkin X-Originating-IP: [65.242.108.162] To: Sergey Babkin , Robert Watson Message-id: <22395548.214801215451968131.JavaMail.root@vms227.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit Cc: arch@freebsd.org Subject: Re: 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 17:33:06 -0000 >>> 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. > >Well, fixing this is easy -- instead of holding a reference to the file >descriptor over the system call, hold a reference to the socket. The problem >with that is that it creates a lot more contention on the socket locks when >the reference count is dropped, not to mention more locking operations. This >can be fixed but requires quite a lot of work, whereas this rather minor >semantic issue is a non-problem in practice. I do have dealing with this I can't comment much without actually looking at the code, but why would the contention on close() be such an issue? Close() is not called that often, compared for example to read(), so there should not be much contention to start with. And why not just call the shutdown() logic from inside close() implementation? -SB