From owner-freebsd-current@FreeBSD.ORG Fri Oct 6 13:33:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 283F116A403; Fri, 6 Oct 2006 13:33:23 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: freebsd-current@freebsd.org, Daniel Eischen Date: Fri, 6 Oct 2006 21:33:17 +0800 User-Agent: KMail/1.8.2 References: <20061004203715.GA38692@xor.obsecurity.org> <200610061711.14517.davidxu@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610062133.17458.davidxu@freebsd.org> Cc: Dmitry Pryanishnikov 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: Fri, 06 Oct 2006 13:33:25 -0000 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 people > > 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. since our AIO is integrated with kqueue and POSIX signal event, I don't know how to implement them in userspace, also our POSIX signal event is reliable (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