Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-08 14:52:55


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk