MOO-cows Mailing List Archive
Re: read() subtlety
On Thu, 12 Sep 1996, Gustavo Glusman wrote:
> The manual says:
> * The `read()' function also suspends the execution of the current task, in
> this case waiting for the player to type a line of input. When the line
> is received, the task resumes with the `read()' function returning the
> input line as result. These are called "reading tasks".
> And also:
> - Function: str read ([obj CONN [, NON-BLOCKING]])
> Reads and returns a line of input from the connection CONN (or, if not
> provided, from the player that typed the command that initiated the
> current task). If NON-BLOCKING is false or not provided, this function
> suspends the current task, resuming it when there is input available to
> be read. If NON-BLOCKING is provided and true, this function never
> suspends the calling task; if there is no input currently available for
> input, `read()' simply returns 0 immediately.
> This seems to imply that read() *always* suspends, even if input is
> already available thorugh that connection. But the behaviour seems to
> suggest that some of the read() calls are not suspending? How else
> could it run out of ticks on line 10?
If there is input available, read() returns immediately without
If there is no input available, and the NON-BLOCKING flag is present and
true, read() suspends and returns when input is available.
If there is no input available, and the NON-BLOCKING flag is present,
read() does not suspend and returns 0 immediately.
This is analagous to UNIX sockets blocking network functions; just because
a function is capable of blocking doesn't mean that it will. I would
agree, though, that the documentation is slightly misleading.
ResComp Network Support Technician, Bursley Hall
"Invisibility is in the eye of the beholder."
Home Page: http://www-personal.engin.umich.edu/~cunkel/
- read() subtlety
- From: Gustavo Glusman <firstname.lastname@example.org>
Subject Index |