Re: aio co-op with socket kqueue on Netbsd

[LeiMing <lmforreg%gmail.com@localhost>]

Justin Cormack <justin <at> specialbusservice.com> writes:

> 
> On Tue, Sep 2, 2014 at 2:19 PM, LeiMing <lmforreg <at> gmail.com> wrote:
> 
> Generally on Unix, people do not use file aio, unlike on Windows. The
> interfaces are new, poorly standardised, only partially async anyway.
Quite surprised that Unix programmers generally don't use asynchronism I/O
APIs on regular files and use threads instead.
> 
> Yes that is one of the older, less useful APIs. Traditionally these
> APIs were usually implemented in userspace using threads, with no
> kernel support at all, hence the lack of kernel completion
> notification semantics in the specification.
> 
> The only one that can provide a sane performant interface is kqueue.
> Your best bet would be to implement this on NetBSD if you really want
> it.
> 
> Well most of the event libraries use threads on Unix (eg libuv AFAIK).
> 
> Using signals is not going to perform very well, I would not do that...
For the lack of implementation of realtime signals, maybe "settimer" api can
be used to handle client's timeout. It's not "realtime signals" so kqueue can
monitor it. Could you tell me whether use kqueue on signals will still have
that bad effect on performance? If not, how do unix programmers usually
implement "timeout"?

> 
> You have to understand that Unix aio has no real history, largely
> because IO goes through the page cache and there is no async semantics
> for a page fault. This is why when aio has been grafted on it tends to
> go via non cached IO, which is not terribly performant. It also tends
> to block in metadata operations and so on (eg no Unix supports an
> async fsync as far as I know). Windows always had a different
> semantics, hence the mismatch you are seeing.
> 
> If you want to work on the kernel and make aio kqueue work, by all
> means do. If you want to run async applciations, use an existing
> library, or ignore file operations and just run a few more threads is
> a good strategy for many applications - the best strategy depends on
> the application.
> 
> Justin
> 
> 
I'll focus my learning on kqueue and epoll.
Thank you for the explaination.

Regards,
LeiMing