Matthew Mondor wrote:
> However:
>
> Although I see that kqueue provides good and efficient mechanisms to
> handle network I/O polling, I noticed lately that it doesn't provide
> similar functionality for disk I/O (or at least the man page doesn't
> mention that it might work on other descriptors than sockets, pipes,
> FIFOs and vnodes (for modification notification)).
>
> After a short exchange on IRC it appeared that AIO would be a feature
> which we're missing to allow I/O asynchroneous operations and polling
> for disk I/O.
[...]

> Do others agree that an M:N implementation without SA done with a
> user-space scheduler would greatly benefit from AIO?  If so, were there
> ever plans for AIO to eventually be implemented on NetBSD?  What are the
> known challenges involved that prevented such a feature so far, if any?
> Other than the buffer cache, DMA and interrupts handled by drivers and
> limited part of VFS, UFS layout, the rest of the disk I/O system is
> still currently unknown to me.
>   
If AIO will be implemented, please do not forget to also implement the 
functionality for kevent on
disk I/O too (e.g. prefetch data in the kernel for EVFILT_READ and 
return the number of available bytes
or return the free bytes in a kernel buffer that can be written without 
blocking), taking also NFS
into account.

I've been playing with a kevent based scheduler for python greenlets (a 
form of
having multiple non-preemptive cooperative tasks in the same thread that 
can be switched by
saving and restoring the stack and interpreter state, similiar to what 
GNU pth does on the C-level)
and it could really benefit from kevent working for disk I/O.

And in order to have threads cooperate non blocking,. it would be really 
helpful to kevent() on
threads too, e.g. for a join event, as thread.join  blocks 
unconditionally, no way to either wait
for I/O or thread.join without busy looping.

Joachim