(In reply to Doug Turner (:dougt) from comment #1)
> lets add locking around the domain resolution and ifdef it for #android.
> This should only be done for pre-honeycomb (i think). jim, want to throw up
> a patch?
wow. That could have such a huge negative impact. We need parallelism on high latency operations.
Do you have a pointer to the android getaddrinfo() implementation in question? I can't find it because android.git.kernel.org is still offline. Is the io conditional on anything - a lazy init perhaps?
Maybe we can clone that code and remove the stdio (or just lock it?)?
If we really are forced to go down this path I would prefer MAX_RESOLVER_THREADS_FOR_ANY_PRIORITY, and MAX_RESOLVER_THREADS_FOR_HIGH_PRIORITY were changed into prefs that could be set to {1,0} for this case rather than the lock. But I really think that's a big step back for phones as modern as gingerbread!
(In reply to Doug Turner (:dougt) from comment #1)
> lets add locking around the domain resolution and ifdef it for #android.
> This should only be done for pre-honeycomb (i think). jim, want to throw up
> a patch?
wow. That could have such a huge negative impact. We need parallelism on high latency operations.
Do you have a pointer to the android getaddrinfo() implementation in question? I can't find it because android. git.kernel. org is still offline. Is the io conditional on anything - a lazy init perhaps?
Maybe we can clone that code and remove the stdio (or just lock it?)?
If we really are forced to go down this path I would prefer MAX_RESOLVER_ THREADS_ FOR_ANY_ PRIORITY, and MAX_RESOLVER_ THREADS_ FOR_HIGH_ PRIORITY were changed into prefs that could be set to {1,0} for this case rather than the lock. But I really think that's a big step back for phones as modern as gingerbread!