On Wed, Mar 6, 2013 at 6:37 AM, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> > > > Whether that's reported as an error is really a choice of the bindings. > In > > C it's all just return codes. We could add a separate non-blocking flag > > that causes the blocking operations to return distinct error codes, i.e. > > the equivalent of EWOULDBLOCK, but I don't think this makes a whole lot > of > > sense in C. I can buy that in the higher level bindings the extra flag > > would tell the API whether to signal timeout by returning false vs > throwing > > an exception. > > > > With the Java implementation (not just the binding) I would expect an > (expensive) exception to be thrown here. I don't think you should be > triggering an exception for a non-exceptional condition. > How do you decide whether it's an exceptional condition or not? It seems like it's really down to how the app is designed as to whether timing out is normal or exceptional. > > > I do agree that we'll want a work interface at some point, but I've been > > thinking that would not just do the work, but also tell you what work has > > been done, so you can, e.g., go check whatever tracker statuses may have > > been updated. > > > > Yeah - i think what you are currently suggesting is more of a "you can > get round the lack of an explicit API because this sort of does the > same thing if you squint at it". Calling a blocking method with a > zero timeout is a hack to cover the lack of a method for the desired > semantic. Moreover if this is a recommended use case for send then I > think you'd need to document it, which would really muddy the waters > as to what "send" is. I'm suggesting it as a way to avoid adding a do_work() call because I'm not actually clear on how you would use the latter without busy looping or what scenarios you would document its use for. I'm not saying there aren't any, but it's not obvious to me right now. If you imagine the split between the non blocking and blocking portions of the API, where all the blocking portions are of the form do_work_and_block_until_condition_X_is_met, we now have two conditions: - the outgoing queue is empty - the incoming queue is non empty What you're asking for is to add a third condition that is always true, and I can possibly buy that for logical completeness, but in terms of usefulness I actually think expanding the set of conditions is actually more interesting, e.g. adding something like "the outgoing queue is < N" perhaps via an optional parameter to send would seem to have a direct and obvious use for pipelined publishing in a way that wouldn't require busy looping. --Rafael
