On Mon, 10 Jan 2011, Vsevolod Novikov wrote:

> Suggestions.

Thank you!

[cut]

Yes, by making a (cleaner) internal API for async resolvers we could indeed
make it much easier for people such as you to add custom ones. Your suggestion
seems fair and even if I didn't review all the details, I think I agree with
the general concept.

Of course, this is just a theory exercise until somebody actually steps up and
produces code that adapts what we have to this/a new internal API. We did a
cleanup of the SSL backend situation a while back in a similar spirit and that
cleaned up a lot.

We don't have any outstanding bugs in our resolver code, for any of the
backends, and we have very few users wanting to use a custom one so there's
not a large push to make this happen.

Feel free to start working on this overhaul, I will certainly assist and
review code and whatever as much as I can.

>> if this really is a libcurl bug then you should be able to provide a
>> recipe that we can use to repeat the problem in our ends.
>
> To reproduce a bug, you should:
> 1. Be registered as AirplaySDK developer (pay-free)

No I won't.

If this is a true libcurl bug (with or without a threaded/async resolver), you
should be able to produce it on whatever Linux system of your choice and you
should be able to show us code that we can run without having to register
anything anywhere. I would urge you to work on making the bug trigger on a
vanilla Linux using libcurl if you want help to get the problem fixed.

Unless you can provide that and as long as you claim AirplaySDK is required to
make the bug happen, I will insist that the bug is caused by your app, by your
resolver or by something else in the AirplaySDK.

> If i am trying to run the example in the debug mode step-by-step - all
> things work fine! If I am switching debug printing on - all things work
> fine! It looks very close to memory overwriting error, and I don't know how
> it will break your code. I've spent already 4 or 5 days and nights to
> resolve the issue, and doesn't find anything. It's a mess.

Just another reason to run it on x86 Linux using valgrind. (Valgrind works on
a few other platforms too these days but I believe the x86 Linux version is
the most mature and reliable one.)

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html