there are so many variants of what people think 'asynchronous IO' should
look like - i'd not like to limit them. I agree that once a particular
syslet script becomes really popular, it might (and should) in fact be
pushed into a separate system call.
But i also agree that a one-shot-syscall sys_async() syscall could be
done too - for those uses where only a single system call is needed and
where the fetching of a single uatom would be small but nevertheless
unnecessary overhead. A one-shot async syscall needs to get /8/
parameters (the syscall nr is the seventh parameter and the return code
of the nested syscall is the eighth). So at least two parameters will
have to be passed in indirectly and validated, and 32/64-bit compat
conversions added, etc. anyway!
The copy_uatom() assembly code i did is really fast so i doubt there
would be much measurable performance difference between the two
solutions. Plus, putting the uatom into user memory allows the caching
of uatoms - further dilluting the advantage of passing in the values per
register. The whole difference should be on the order of 10 cycles, so
this really isnt a high prio item in my view.
no, threadlets dont really solve the basic issue of people wanting to
'combine' syscalls, avoid the syscall entry overhead (even if that is
small), and the desire to rely on kthread->kthread context switching
which is even faster than uthread->uthread context-switching, etc.
Furthermore, syslets dont really cause any new problem. They are almost
totally orthogonal, isolated, and cause no wide infrastructure needs.
as long as syslets remain a syscall-level API, for the measured use of
the likes of glibc and libaio (and not exposed in a programmable manner
to user-space), i see no big problem with them at all. They can also be
used without them having any classic pthread user-state (without linking
to libpthread). Think of it like the raw use of clone(): possible and
useful in some cases, but not something that a typical application would
do. This is a 'raw syscall plugins' thing, to be used by those
user-space entities that use raw syscalls: infrastructure libraries. Raw
syscalls themselves are tied to the platform, are not easily used in
some cases, thus almost no application uses them directly, but uses the
generic functions glibc exposes.
in the long run, sys_syslet_exec(), were it not to establish itself as a
widely used interface, could be implemented purely from user-space too
(say from the VDSO, at much worse performance, but the kernel would stay
backwards compatible with the syscall), so there's almost no risk here.
You dont like it => dont use it. Meanwhile, i'll happily take any
suggestion to make the syslet API more digestable.
Ingo
-
