Date: Wed, 18 Oct 2006 13:46:42 -0400 From: sbahra@kerneled.org To: David Xu <davidxu@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>, freebsd-current@freebsd.org Subject: Re: Thread stuck in aioprn Message-ID: <20061018134642.0ttsbjhlz6gc8okg@www.kerneled.org> In-Reply-To: <200610062133.17458.davidxu@freebsd.org> References: <20061004203715.GA38692@xor.obsecurity.org> <200610061711.14517.davidxu@freebsd.org> <Pine.GSO.4.64.0610060842560.17773@sea.ntplx.net> <200610062133.17458.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, What were the results of this discussion? Kris, was this indeed the =20 case for the problem you were encountering? Regards. -- Samy Quoting David Xu <davidxu@freebsd.org>: > 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 peop= le >> > 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. In general, asynchronous I/O should be out-performing synchronous =20 primitives. A threads implementation simply cannot scale or perform as =20 well as a kernel-space implementation (for various reasons). http://www.linuxsymposium.org/proceedings/reprints/Reprint-Bhattacharya-OLS2= 004.pdf > since our AIO is integrated with kqueue and POSIX signal event, I don't kn= ow > how to implement them in userspace, also our POSIX signal event is reliabl= e > (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 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061018134642.0ttsbjhlz6gc8okg>