On Sat, 18 Nov 2017 14:09:31 -0500, Demi Marie Obenour said: > Only whitelisted system calls would be allowed, such as open(), read(), > and write(). Async getuid() would not be allowed. Nor would async > exit() or exit_group(). You missed the point - If you allow async calls, you need to deal with the fact that this can change the semantics of things and introduce race conditions. What semantics does an async open() have? Under what conditions does open() take long enough that doing it asyncronously provides a benefit? What system calls are you going to allow to be async? (Hold that thought for a moment, we'll return to it...) > If an async call fails, the packet posted to the file descriptor > contains the negative error code. OK.. Was that a -5 error from async() itself, or a -5 from the async read()? > Many programs (such as Node.js, NGINX, Firefox, Chrome, and every other > GUI program) use an event loop architecture. To maintain > responsiveness, it is necessary to avoid blocking calls on the main > thread (the thread that runs the event loop). For filesystem > operations, this is generally done by doing the operation in a thread > pool. And somehow, all those event loops are able to work just fine without adding kernel infrastructure. Given that track record, you'll need to show a *large* benefit in order to get it into the kernel. Hint: kdbus didn't make it in. > There was a previous attempt to implement async system calls using the > AIO interface. Linus rejected it on the basis that an async system call > API should be more general. Do you have enough system calls to make it more general than AIO?
Attachment:
pgpfLE87bKDO3.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
