[getdns-api] async comments (0.268)

[Joe Hildebrand jhildebr]

There are several subtle points in the API that work together:

1) You MUST check the return code.  If the status is OK, the API
guarantees that the callback will be called exactly once for this
transaction at some unknown point, including the past (from the standpoint
of the caller).  If the status is not OK, the API guarantees that the
callback will not be called ever for this transaction.
2) If you call cancel on an transaction_id that is not currently pending,
it's a no-op.
3) If the return code was not OK, the transaction_id should be filled in
with a transaction_id that is never pending, such as 0, 2^n-1, etc.
4) If you cancel a pending transaction, the callback will be called
exactly once with a cancellation status, and NOT called when the results
finally do arrive.
5) If the request times out while pending, the callback will be called
exactly once with a timeout status, and NOT called when the results
finally do arrive.

Now, you can use the transaction_id with impunity whenever you like after
the initial call returns.

On 2/12/13 6:10 AM, "Dan Winship" <dan.winship at gmail.com> wrote:

>On 02/09/2013 08:28 PM, Paul Hoffman wrote:
>> So the only possible place for error is if the application
>> changes userarg in the callback in a way that later code in
>> main() is not expecting. But isn't that true of *any* async
>> system? Assume your example was instead:
>>
>>  status = getdns (context, name, GETDNS_RRTYPE_A, NULL,
>>                   myuserdata, &transaction_id, mycallback);
>>  . . .  // Some commands go here
>>  myuserdata->id = transaction_id;
>>
>> Then if the callback arrived after getdns() returned but where
>> the ellipsis is, you would be hosed in exactly the same way as
>> if the callback had been called before getdns() returned.
>
>Yes, this is what Phillip Hallam-Baker and I were discussing earlier in
>the thread; I was assuming that (a) getdns() would not create any
>threads of its own internally, and (b) getdns() could only be called
>from the same thread that its event loop was running in. So normally,
>the callback would not be invoked until the caller returned control to
>the event loop, unless getdns() invoked it directly before returning,
>and I was suggesting "don't do that".
>
>If (a) is wrong, then I don't understand why you need an event loop at
>all, since getdns() could just be doing its work synchronously in that
>case. And if (b) is wrong, then section 8 needs to be updated, since it
>currently says that "a context should not be used by multiple threads",
>and it seems like calling getdns() from a thread other than the one that
>its event loop is running in would violate that.
>
>-- Dan
>
>_______________________________________________
>getdns-api mailing list
>getdns-api at vpnc.org
>



-- 
Joe Hildebrand