Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

My textbook mentions it but doesn't specifically define it. From the context it's used in (in this example, pipes), I take it to mean that if one end of the pipe blocks, it's temporarily "disabled", if you will, and data is queued? That's the part I'm a bit confused about. When it "blocks", does (whatever it is) wait until it's unblocked and then continue with whatever was sent while it was blocked? This seems to be what they're hinting at because they say when it's "non-blocking" it immediately returns an error (if I remember correctly). Any clarification or nudges in the right direction appreciated. Thanks!

(Not sure which tags to use)

share|improve this question

2 Answers 2

up vote 7 down vote accepted

A blocking call will return when there is data available (and wait for said data), a non-blocking call will return data if there is data to return, otherwise returns an error saying there's no data (but always returns "immediately" after being called).

Whether you use one or the other depends on what you want to do — if you want to get that data and there's nothing else to do, you just call a blocking call. But sometimes you want to do something else if there's no data yet.

See also select(), the POSIX swiss knife for "is there any data?" kind of calls, featuring blocked calls on several file descriptors, which may be timed (so, if there's no input for five minutes, you can have it return with an error).

share|improve this answer

If an I/O operation blocks, then the function/system call that initiated it will not return control to the process/thread until an appropriate amount of data has been read or written.

share|improve this answer
    
Not quite: a blocking operation will return as soon as some data (at least one byte) has been read or written. A blocking I/O operation can perform a partial read or write. –  Gilles Feb 7 '12 at 0:08
    
@Gilles: Fixed. –  Ignacio Vazquez-Abrams Feb 7 '12 at 0:12
    
@Gilles, note that as a rule, blocking io on sockets and pipes can return less than the requested amount of data, but on regular files, the full amount is always done ( unless there's an error ). –  psusi Feb 7 '12 at 0:37
    
@psusi Even on regular files, the full amount is not guaranteed. See e.g. Susv3 read: “The value returned may be less than nbyte if the number of bytes left in the file is less than nbyte, if the read() request was interrupted by a signal, …” –  Gilles Feb 7 '12 at 0:46
    
@Gilles, the spec allows for the possibility, but as far as I know, no implementation works that way. If the system call is interrupted, you get zero bytes and errno is set to EINTR. –  psusi Feb 7 '12 at 2:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.