Why are write calls blocking?

[marwen Bakkar]

It's obvious why a read on an InputStream can block, but why would a write to an OutputStream block? The only scenario I can think of is when you're requesting writing at a faster rate than the station's network upload rate. Is that correct? What are there other reasons?

[Paul Clapham]

What's the point of enumerating possible reasons?

Anyway a write will always block for a short period of time because nothing happens instantaneously. You only really care if it affects the throughput of your application badly enough to cause a problem. And does it?

[Jeff Verdegan]

marwen Bakkar wrote:It's obvious why a read on an InputStream can block, but why would a write to an OutputStream block? The only scenario I can think of is when you're requesting writing at a faster rate than the station's network upload rate. Is that correct? What are there other reasons?

It's just like any other operation you perform: You invoke the method, and when it's done, it returns. It's a synchronous operation, just like any others are unless steps are taken to make them otherwise (i.e., multirhreading).

[marwen Bakkar]

Paul Clapham wrote:What's the point of enumerating possible reasons?

Anyway a write will always block for a short period of time because nothing happens instantaneously. You only really care if it affects the throughput of your application badly enough to cause a problem. And does it?

Consider a chat server that's constantly broadcasting messages to multiple clients using TCP. The server has a message queue from which a dispatcher thread polls messages and dispatches them to the clients. During the iteration on the client list, if one iteration gets stuck on writing then service time suffers for the rest of the list. I need to know why and how often would that happen.

[Clivant Yeo]

Write calls block because the receiver of the data you are writing to is not ready to receive the data.

For instance, when writing to file, the operating system needs time to get/create the file before populating it with data.

Similarly, in TCP/IP, the process that is receiving your data needs to be "listening" to your data before your write can proceed. In such a case, if you find that your writing process blocks infinitely, you can know for sure that you need to revise your communication protocol between your write and read process. In a way, blocking also helps in debugging communication protocol related errors.

Just my 2 cents. ;)

[Paul Clapham]

marwen Bakkar wrote:I need to know why and how often would that happen.

It isn't possible to answer the question "how often" for a hypothetical server running on an unknown network with an unknown number of clients. Even if you knew all of those things in detail you still wouldn't be able to predict how often it would happen. If you have to know everything in advance then perhaps network processing is not for you.

[marwen Bakkar]

Yeah I know it's hard to answer and I have no means to test it because I'd need a real world scenario with actual users on my server. I thought if I could figure out the reasons that could cause it maybe I would have some insight as to how likely it will occur.
This is related to an important design decision in a project I'm working on. If it's not uncommon for a write on a socket to block for a significant time, then to avoid bad service time for subsequent sockets in the loop maybe it would be better to use Async IO in release 1.7, which allows you to request a write operation and move on. That way a slow write operation doesn't hurt what comes next. Do you know any reliable open source chat server I can look at?

[marwen Bakkar]

To answer the question, It turns out the solution is simple with NIO. try to write in non blocking mode, if it succeeds we're done. If not, see how many bytes have been written and queue the bytes that haven't. Subscribe to write readiness for the channel. When it is, write the queue. I saw this in the kryonet library.