in reply to Filehandles and can_write, actual writable amount?

I'll assume you meant can_write (as the title of your question says) instead of can_read (as the body says).

The answer is that you simply don't know how much you can write. Do a syswrite of the stuff you want to write and then check the returncode to see how much actually got written. Remove that many bytes from the front of your buffer and if anything is still left, you'll have to check for can_write again before trying to write the rest. In principle you should have been able to write at least one byte, but on some operating systems it's possible that the available internal bufferspace got reused by the time you do the actual syswrite and the write can then block if the socket is blocking. That's why you should set your sockets to non-blocking even if you write a select-driven program, so that you'll get errno EAGAIN in that case (I never work on windows, but I believe there you would get EWOULDBLOCK instead. On UNIX these two are normally #defined to be equal).

(updated) It's also possible that the socket got closed (or half-closed) in the mean time, in which case you will get SIGPIPE when you try to write, and an EPIPE errno (which you'll only see if the program catches, blocks or ignores the signal). Beyond that you should consider every error return except EAGAIN or EINTR as fatal to your socket.

Notice that something like POE will take care of all these details for you.

  • Comment on Re: Filehandles and can_write, actual writable amount?

Replies are listed 'Best First'.
Re^2: Filehandles and can_write, actual writable amount?
by BUU (Prior) on Oct 08, 2004 at 20:04 UTC
    Yeah, you are completely correct, I did mean can_write and not can_read. Your explanation was extremely succinct, explicit and helpful, thanks.