> Hmm... What do you mean with that ? (I am curious, as one of my
> larger hats is MTA writer.. Reply privately, this is off-topic to
> Linux. )
Line length >> 80 chars. Just a nit-pick. Technical nothing wrong with it. I
thid you were using M$ outlook or whatever, which would explain it.
> File-IO on regular files is convertable into non-blocking. Consider for
> example current system of waiting for indirection blocks or data-blocks
> deep within filesystem codes. (Say, average random block access on the
> disk takes about 5 milliseconds. Instead of blocking for that the system
> could do retrying of the file-io in non-block mode to wait for the
> availability of the file block.)
You need some kind of schedulable context for non-blocking file open, read,
write and close. Considered a process opening, and read 10MB of data of a
_really_ slow device, or NFS for example.
Also, what do non-blocking really man? For network IO, it means the process
never sleeps waiting for data - something that can also happen with files
(e.g. NFS), however, for disk based file IO, the process will enter
uninterruptable sleep - is this blocked?
Network call when sleeping can be abort with a signal, thats not necessarily
possible with block-device sleeping IO.
And all this is very well, but if you can't tell when the IO finished is a
nice efficient way, its not much good. This means changing the semantics of
select(2) and poll(2) for filesystem FDs, which may violate POSIX (Anyone?).
> To realize that does need changes in the filesystem codes, though.
Why?
> A thing to consider in 2.3.* series.
I'm not so sure any kernel changes are required. I started out thinking that
way, but now I think it may be possible to make do with libpthread and some
wrapping around libc. (Albeit somewhat suboptimal that way you'll have to
pull apart fdsets and so on).
-cw
-
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.altern.org/andrebalsa/doc/lkml-faq.html