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 XuReceived 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