[MUD-Dev] Re: lurker emerges
T. Alexander Popiel
popiel at snugharbor.com
Mon Aug 10 08:29:40 CEST 1998
In message: <35CE83C9.62363952 at freehold.crocodile.org>
Vadim Tkachenko <vt at freehold.crocodile.org> writes:
>
>I guess we differ in the definitions, or rather I'm ignorant about ones.
>
>Can you please give me a brief definition of a blocking and non-blocking
>I/O?
Hmm. Okay, definitions are always good. :-) They promote
communication, as opposed to vociferous noise.
My definitions of blocking and non-blocking I/O are as follows:
Blocking I/O: you make a library/system call requesting an I/O
operation of a given size. The call does not return until the
entire operation completes for the entire size requested,
regardless of delays incurred. Under some implementations,
external (and only external) sources may interrupt the call.
Under no circumstances is your program able to do other work
while waiting for the I/O to complete.
Non-blocking I/O: you make a library/system call requesting
an I/O operation of a given size. The call always returns
'immediately' (after minimal processing of the request,
responding with whatever data is already on hand), with an
indication of how much I/O was actually performed. In some
implementations (UNIX sockets), no further processing is done
without additional request. In other implementations (Amiga,
apparently, and some of the old mainframes), when the remainder
of the requested I/O is completed, the calling program is
informed. In both cases, a _separate_ library/system call is
available to wait until more I/O is possible or I/O completes
(depending on flavor).
The most important distinction in my mind is the ability (or
lack thereof) to separate the request and the wait for request
completion.
In other news, the thread I referenced earlier (about using
select() more effectively) is: "I/O Event Handling Under Linux
by Richard Gooch", fetchable from the archives at:
URL:http://www.kanga.nu/~petidomo/lists/mud-dev/1998Q2/msg01208.html
- Alex (who seems to have spawned quite the tempest)
More information about the mud-dev-archive
mailing list