[Freeipa-devel] [RFC] Integration of c-ares and tevent

[Martin Nagy]

Simo Sorce wrote:
> On Mon, 2009-06-29 at 19:04 +0200, Martin Nagy wrote:
> > Hi,
> > we (me and Jakub) are working on integrating the c-ares [1] asynchronous
> > DNS resolver library with tevent, to be used in SSSD. The result of our
> > work so far is the attached source file that demonstrates how it would
> > be used in SSSD. We would like some comments before we start
> > integrating it directly into SSSD.
> 
> The tevent_req interface seem perfect for something like this.
> I would like to see an interface built using that convention.
> 
> I am finishing working on a big rewrite of the sysdb and native ldap
> driver to use tevent_req and it looks really nice.
> I'll try to post patches as soon as I am done (been working the last 5
> days including w/e, mostly boring conversion, but to me the code looks
> much better).

I just spent couple of hours trying to grasp the tevent_req interface
and then trying to use it with resolv.c. Unfortunately, I hit many
problems and I think we should just stay with the first version.

One thing I really hate is that you create a tevent_req inside a
function, return it, and only then will the caller set the
callback. This might be all well and good for our code, but ares can
call its callback immediately and that's a problem. It could be solved
by using tevent_req_post(), but after ares calls the callback you give
it and before it returns, it will destroy the hostent struct, so you
have to copy the whole thing. And, another problem is that you don't
even know if the user did set the callback or not, so the
tevent_req_post() will cause the callback to be called two times, argh!
I tried to resolve this by using a "default callback" to be used if
ares calls it immediately. User would then overwrite it. But I hit some
other problems and I'm really sick of it at this moment, so I just quit
for now.

So, I'm in favor of using the old way. I can try some more if you want,
but IMHO it's a waste of time. The pros of using tevent_req is a
unified interface, which really is a good thing, but not necessary easy
to do if it's not your code that has to call the callback. On the other
hand, I can see a big advantage of our current approach. Basically,
almost every function you use takes a different callback type. This at
least provides some type safety during compile time. Tevent has some
checks through talloc, sure, but only during the runtime. It also
saves you from having a ton of structs (you could use unions in one
struct, but this could be dangerous if you're accessing the wrong union
member).

So in the summary, yeah, tevent_req is nice but IMHO not very suitable
for this particular task. Does anyone have any comments on this?

Sorry for the long rant.

Martin