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:

Follow-Ups: References:

Home | Subject Index | Thread Index