M
Martin Gregorie
Yes, I agree that it is technically single threaded programming andYes, I know, but its not relevant to a single-threaded process sinceMost OS'es support async IO.
its logic generally requires it to wait for a read or write to complete
before it continues[1]. Hence my comment that this prevents head
movement being optimized unless a lot of processes are active because
there's only one outstanding IOP per process.
[1] unless you're deliberately doing async i/o using poll() or
select() (in C) or nio (in Java), in which case the process is
often best regarded as a half-way house between single and
multi-threaded logic.
I am talking about deliberate not accidental async IO.
And you maybe consider it half singlethreaded half multithreaded,
but when there is only one thread it is usually just called single
threaded.
therefore dodges a lot of problems associated with threading (especially
in C).
Nonetheless most of the async i/o I've seen in C ends up treating
transfers to and from a channel as a connected set of transfers, i.e.
some context is associated with the channel and is kept distinct from
context associated with other channels. The use of context implies having
dedicated data storage for that channel, so from some viewpoints the
logic of the program is indistinguishable from that used in a threaded
approach. I can't comment about nio in Java since I haven't yet needed to
use it.
Anyway, that's what I meant by the mongrel 'half-threaded' term.