Thread stuck in aioprn

[sbahra at kerneled.org]

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