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