Hi, What were the results of this discussion? Kris, was this indeed the case for the problem you were encountering? Regards. -- Samy Quoting David Xu <davidxu_at_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 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. In general, asynchronous I/O should be out-performing synchronous primitives. A threads implementation simply cannot scale or perform as well as a kernel-space implementation (for various reasons). http://www.linuxsymposium.org/proceedings/reprints/Reprint-Bhattacharya-OLS2004.pdf > 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 > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Wed Oct 18 2006 - 15:46:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC