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