>> to me that the only efficient way of implementing an event based
>> API would be if an assigned function in a user's program were
>> called whenever data became available for a particular file handle
>> being monitored.
>
> VMS calls these ASTs, and every I/O function that could block accepts one.
> This lets the application programmer definitively answer the question of
> what to do with this I/O completion, instead of making the kernel guess.
> It's a model I've come to appreciate, and if you'd rather be synchronous
> you can call the blocking version (functionW() rather than function() )
Yes! This is good.
> But this would require revamping much of the fundamentals of the I/O code,
> and the result would be so un-Unixy that I don't expect to see it in Linux
It would be trivial to emulate the traditional unix API on top
of this, right? Of course we already have unixy system calls.
> And you're right -- it requires at least some support from the kernel.
> Making sync. I/O appear to be async. is much more difficult in userspace
> than the other way 'round. It's a question of keeping decisions close to
> the information required to make them. The kernel knows best what the
> devices are doing, and the application knows best what *it* is doing
> with the results.
:-)
The "everything in userspace" fanatics are just as bad as the
newbies that think everything belongs in the kernel. It is hard
to convince both groups, since every feature can be implemented
in both places.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/