> > 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. > 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. -- Rob
