Re: Thread stuck in aioprn

From: David Xu <davidxu_at_freebsd.org>
Date: Fri, 6 Oct 2006 21:33:17 +0800
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
Received on Fri Oct 06 2006 - 11:33:25 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC