Rob Stewart wrote:
From: "Jonathan Turkanis"
Caleb Epstein wrote:
Jonathan Turkanis
Here are the names I've thought of:
good: good, is_good eof: eof, is_eof fail: fail, eagain, is_eagain, would_block, should_retry
.... eagain is too "unix-y".
Thanks for your feedback. would_block is unix-y too, no?
I don't see how "would_block" can be construed as "unix-y" since it merely indicates that the requested operation would have blocked had it not returned that value.
I got the name from EWOULDBLOCK. Maybe I should have said posix-y?
As for the rest of the choices, I agree that you should keep "good" and "eof," "fail" is awfully general, and I don't think it is the called function's place to tell the caller to try again (eliminating eagain, is_eagain, and should_retry). Thus, from the given choices, I favor "would_block."
Okay, thanks.
If you want it to read better in the source, you could make it, "would_have_blocked:"
if (read(...) == would_have_blocked)
This is not quite the right usage: for read, a "would block" condition is indicated simply by returning fewer than the number of requested characters. Also, I was thinking that would_block would be a function, rather than a constant, though I think it looks good as a constant and will see if I can make it work.
Other options would be:
unavailable if (read(...) == unavailable) not_now if (read(...) == not_now) nothing_now if (read(...) == nothing_now) maybe_later if (read(...) == maybe_later)
:-) I think if you keep calling read like above, the failure messages should get stronger and stronger: if (read(...) == unavailable) { } if (read(...) == unavailable) { } if (read(...) == i_said_unavailable) { } if (read(...) == are_you_a_complete_idiot)
Still, "would_block" seems like the right choice:
if (read(...) == would_block)
Okay. Jonathan