On Wed, Mar 6, 2013 at 5:32 AM, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> On 6 March 2013 13:26, Rafael Schloming <r...@alum.mit.edu> wrote:
> > On Wed, Mar 6, 2013 at 1:44 AM, Rob Godfrey <rob.j.godf...@gmail.com>
> wrote:
> >
> >> On 5 March 2013 21:10, Rafael Schloming <r...@alum.mit.edu> wrote:
> >> > On Tue, Mar 5, 2013 at 11:24 AM, Ted Ross <tr...@redhat.com> wrote:
> >>
> >> [.. snip ..]
> >>
> >> >
> >> > It isn't really possible to have "put" cause messages to be eventually
> >> sent
> >> > without a background thread, something we don't currently have.
> >>
> >> I think it's this that is what makes me find the API slightly odd.
> >> That put is an asynchronous operation is fine, but the fact that the
> >> only way to get work to occur is for a synchronous operation to be
> >> called seems a little screwy.
> >>
> >> If I understand correctly, right now an application programmer cannot
> >> actually write an "asynchronous publisher", every so often they would
> >> have to call some form of synchronous operation.
> >>
> >> At the very least it would seem to suggest there might be call for a
> >> "do some work but don't block" function in the API. This could either
> >> take an aggressive strategy of flushing everything that it can to the
> >> wire, or it could attempt to optimize into larger transmission units.
> >
> >
> > This is exactly what happens when you set the timeout to zero and call
> send
> > (or recv). Are you saying you want some other way of doing the same thing
> > or you want a background thread?
>
> Surely though setting timeout to 0 and calling send results in
> something that looks like an error ("this timed out"). On a Java
> implementation I would expect this to throw an exception. That's not
> really the semantic I'm expecting. The semantic is "do some work if
> you can without blocking".
>
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.
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.
--Rafael
