From owner-freebsd-current@FreeBSD.ORG Wed Oct 18 17:46:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1089D16A62A; Wed, 18 Oct 2006 17:46:58 +0000 (UTC) (envelope-from sbahra@kerneled.org) Received: from perseus.interservers.com (perseus.interservers.com [65.202.242.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BB7943D7E; Wed, 18 Oct 2006 17:46:47 +0000 (GMT) (envelope-from sbahra@kerneled.org) Received: from cpanel by perseus.interservers.com with local (Exim 4.52) id 1GaFV5-0007JQ-3a; Wed, 18 Oct 2006 13:46:43 -0400 Received: from 128.164.160.1 ([128.164.160.1]) by www.kerneled.org (Horde MIME library) with HTTP; Wed, 18 Oct 2006 13:46:42 -0400 Message-ID: <20061018134642.0ttsbjhlz6gc8okg@www.kerneled.org> Date: Wed, 18 Oct 2006 13:46:42 -0400 From: sbahra@kerneled.org To: David Xu References: <20061004203715.GA38692@xor.obsecurity.org> <200610061711.14517.davidxu@freebsd.org> <200610062133.17458.davidxu@freebsd.org> In-Reply-To: <200610062133.17458.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - perseus.interservers.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [32002 32002] / [47 12] X-AntiAbuse: Sender Address Domain - kerneled.org X-Source: X-Source-Args: X-Source-Dir: Cc: Daniel Eischen , Dmitry Pryanishnikov , freebsd-current@freebsd.org Subject: Re: Thread stuck in aioprn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2006 17:46:58 -0000 Hi, What were the results of this discussion? Kris, was this indeed the =20 case for the problem you were encountering? Regards. -- Samy Quoting David Xu : > On Friday 06 October 2006 20:44, Daniel Eischen wrote: >> On Fri, 6 Oct 2006, David Xu wrote: >> > On Friday 06 October 2006 16:50, Dmitry Pryanishnikov wrote: >> >> Hello! >> >> >> >> On Fri, 6 Oct 2006, David Xu wrote: >> >>>> FYI, this has recurred, so it seems to be an easy problem to trigger= . >> >>>> >> >>>> Kris >> >>> >> >>> can you try attached patch ? it disables support for non-disk files, >> >>> I suspect the test passed non-disk file handle to aio, and caused >> >>> the problem. >> >> >> >> I think it must be done as a workaround _only_. What's the point of >> >> having asynchronous I/O capability for relatively fast HDDs while >> >> missing this support for other (slow) I/O such as ttys or pipes? This >> >> situation renders the whole presence of aio almost useless. >> >> >> >> Sincerely, Dmitry >> > >> > We are diagnosing the problem, not trying to remove some capabilities, >> > I also don't have plan to work on it, I have already been overloaded by >> > threading work, it is not a trivial work to implement AIO for all I/O >> > facilities, I believe its amount of work is considerable, and some peop= le >> > are better to start a new project to implement it. >> >> I've always thought that perhaps it could be better done >> in userspace, libaio, with threads. In general, asynchronous I/O should be out-performing synchronous =20 primitives. A threads implementation simply cannot scale or perform as =20 well as a kernel-space implementation (for various reasons). http://www.linuxsymposium.org/proceedings/reprints/Reprint-Bhattacharya-OLS2= 004.pdf > since our AIO is integrated with kqueue and POSIX signal event, I don't kn= ow > how to implement them in userspace, also our POSIX signal event is reliabl= e > (loseless), different than others, implementing it in userland will have > problem. I think we only need directly NON-BLOCK I/O interface in kernel > without have to fiddle with fcntl(fd, F_SETFL, O_NONBLOCK), fcntl has race > with other threads, should be avoided, I heard this has been partly done = by > Matt in DragonflyBSD for their libc_r. > > David Xu > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >