From owner-freebsd-current@FreeBSD.ORG  Fri Oct  6 09:11:21 2006
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 4317816A4A0;
	Fri,  6 Oct 2006 09:11:21 +0000 (UTC)
	(envelope-from davidxu@freebsd.org)
From: David Xu <davidxu@freebsd.org>
To: freebsd-current@freebsd.org
Date: Fri, 6 Oct 2006 17:11:14 +0800
User-Agent: KMail/1.8.2
References: <20061004203715.GA38692@xor.obsecurity.org>
	<200610061116.31469.davidxu@freebsd.org>
	<20061006114529.P61584@atlantis.atlantis.dp.ua>
In-Reply-To: <20061006114529.P61584@atlantis.atlantis.dp.ua>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610061711.14517.davidxu@freebsd.org>
Cc: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Oct 2006 09:11:21 -0000

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.

Regards,
David Xu