Hey again, sorry for the late reply.

> I feel it's safe to exclude or program around NT 3.x systems. But man!
> Does
> it need to be so complex? I've never used APC calls before, so can we
> expect
> a patch from you?

I've just spent some time investigating the matter, and I have reached the
conclusion that APCs are unsuitable to the current scenario.

My idea was to have the resolver thread post an APC to the main thread
with a pointer to the result information. If the main thread would have
still been alertable, it would have read the information. The resolver
thread would have waited for the information to be read (or not), and
freed the result container.

The problem with this is that curl_easy_perform() continues execution on
the user's thread. I was under the impression (through taskmgr
observations) that libcurl spawned a new thread for its perform() calls.
Since this is not the case, we would be modifying the user's APC thread
queue, and any unprocessed APCs would propagate to the user (instead of
being discarded on thread exit). And that's not right.

Well, now that I've wasted both our time with an improperly researched
suggestion, may I suggest a fallback to the mutex idea through the
following patch?

I've tried to modify as little as possible, and to adhere to existing code
style. Both the IPv4 and the IPv6 threads have been changed, but I haven't
run any tests on the IPv6 version.

Let me know. By the way, it's diffed against 7.12.1.

Best regards,
Traian Nicolescu.