Date: Fri, 6 Oct 2006 08:44:26 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: David Xu <davidxu@freebsd.org> Cc: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>, freebsd-current@freebsd.org Subject: Re: Thread stuck in aioprn Message-ID: <Pine.GSO.4.64.0610060842560.17773@sea.ntplx.net> In-Reply-To: <200610061711.14517.davidxu@freebsd.org> References: <20061004203715.GA38692@xor.obsecurity.org> <200610061116.31469.davidxu@freebsd.org> <20061006114529.P61584@atlantis.atlantis.dp.ua> <200610061711.14517.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0610060842560.17773>