From owner-freebsd-current@FreeBSD.ORG Fri Oct 6 12:44:50 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 2FB2B16A407; Fri, 6 Oct 2006 12:44:50 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D674B43D90; Fri, 6 Oct 2006 12:44:39 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k96CiQsQ001943; Fri, 6 Oct 2006 08:44:26 -0400 (EDT) Date: Fri, 6 Oct 2006 08:44:26 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <200610061711.14517.davidxu@freebsd.org> Message-ID: References: <20061004203715.GA38692@xor.obsecurity.org> <200610061116.31469.davidxu@freebsd.org> <20061006114529.P61584@atlantis.atlantis.dp.ua> <200610061711.14517.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-2.0.2 (mail.ntplx.net [204.213.176.10]); Fri, 06 Oct 2006 08:44:27 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: 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 Reply-To: Daniel Eischen 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 12:44:50 -0000 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. -- DE