Re: [gnet-dev] Asynchronous DNS query when nonblocking query is possible

[Tim Müller <t i m zen co uk>]

On Thu, 2006-08-31 at 10:25 -0300, cascardo minaslivre org wrote:

Hi,

> One year later I sent a message regarding using uDNS in GNET, I'm really
> writing it. I would really like to finish it and get it included in
> GNET.

To be honest, I'm not really sure whether it's a good idea to add
further library dependencies to GNet, even more so a dependency on a
somewhat 'exotic' library like libudns that isn't widely packaged. If
someone requires the performance/robustness of such specialised
libraries, they should be using that library directly IMHO (not that
improvements to GNet aren't welcome, it's just that GNet is targeted at
people with different needs).


> The first thing I am working on is getting nonblocking queries (those
> with a decimal dot notation address instead of a real DNS name) not to
> dispatch a new thread or process.
> 
> However, that would require calling the callback function before even
> returning the new_async functions. Would that be a problem?

You can't really do that (calling the callback function before returning
from new_async) I'm afraid. The documentation explicitly states that the
callback will not be called before the function returns. Changing that
would mean breaking backwards compatibility.

However, if the fork/thread creation overhead is your main concern, what
would be possible is to try gnet_inetaddr_new_nonblock() or similar
first in _new_async() and if successful set up an dispatcher idle
callback right in _new_async() without creating the thread or forking.
That saves you the fork/thread overhead and maintains the current API
semantics. 

> Which AsyncID should I return? I've noticed that AsyncID is, in fact, a
> pointer to a State, and it seems applications are responsible not to
> call cancel when the callback function was already called (when state
> would be freed). So, returning a NULL ID would be the right way, since
> cancel would also return without failure even in case the application
> called cancel.

You must return some kind of non-NULL AsyncID, since returning NULL
indicates failure according to the API documentation.

(Alternatively, you could introduce new API of course, but you would
need to have a reasonably good argument for why that's needed).

Cheers
 -Tim