Re: SCNetworkCheckReachabilityByName causing spinning cursor
Re: SCNetworkCheckReachabilityByName causing spinning cursor
- Subject: Re: SCNetworkCheckReachabilityByName causing spinning cursor
- From: Allan Nathanson <email@hidden>
- Date: Mon, 7 Mar 2005 11:06:28 -0500
SCNetworkCheckReachabilityByName() is a synchronous API and, as such,
you need to wait for it's return. To help matters we introduced a
new set of APIs (in Panther) which can provide an asynchronous
notification when a target host/address is reachable. Check out the
sample code at :
http://developer.apple.com/samplecode/SimpleReach/SimpleReach.html
- Allan
On Mar 7, 2005, at 10:54 AM, David Niemeijer wrote:
At 10:34 -0500 7/3/05, Allan Nathanson wrote:
If you look at the call stack you will note that
SCNetworkCheckReachabilityByName() is calling getaddrinfo() to
resolve the provided name. This call is made after we have
determined that the DNS server addresses are reachable. In this
case, the query has been passed to lookupd and we're waiting for a
response.
And why would that take so long? Also, it appears that in this case
the address is reported as unavailable as the version check does
not proceed. Manual version check (which does not call
SCNetworkCheckReachabilityByName) is instant on that same machine
(high speed cable connection).
Is there a way to prevent SCNetworkCheckReachabilityByName to
result in locking down my app. It may be of interest to note that
this user had serious connectivity problems with 10.3.7 (Safari
worked fine, but plenty apps stalled in their version checking
routines on launch, e.g. StuffIt), which were resolved with 10.3.8,
though now it seems that not all network issues were resolved with
that update. Or is it normal for SCNetworkCheckReachabilityByName
to (1) take a long time and (2) report a site as unavailable where
an actual http request to the site is instant.
Thanks,
david.
- Allan
On Mar 5, 2005, at 7:37 AM, David Niemeijer wrote:
I am using SCNetworkCheckReachabilityByName to check whether
there is a good internet connection (before running my version
check code). One user is now reporting recurrent spinning cursors
and I asked him to use Spin Control. From the Spin Control report
it turns out that each time he sees a spinning cursor it happens
with SCNetworkCheckReachabilityByName. The interesting thing is
that his network works fine (cable) and that if he does a manual
version check (for which I do not call
SCNetworkCheckReachabilityByName) the check instantly reports
that the software is up-to-date. He is running 10.3.8. Anyone
else seen something like this before?
Would using SCNetworkCheckReachabilityByAddress not show this
behavior? In other words, is this DNS related? (though of course
it would still be silly that fetching something using a name is
much faster than simply masking whether that name is reachable)
The Spin Control report is included at the bottom of this message.
david.
---
Call graph:
1330 Thread_5f03
1330 start
1330 start
1330 main
1330 RunApplicationEventLoop
1330 AcquireNextEventInMode
1330 ReceiveNextEventCommon
1330 RunCurrentEventLoopInMode
1330 CFRunLoopRunSpecific
1330 __CFRunLoopRun
1325 __CFRunLoopDoTimer
1324 RegisterableApp::VersionTimer
(__EventLoopTimer*, void*)
1324
NetworkManager::UnsolicitedAllowedSCF(char const*)
1324 SCNetworkCheckReachabilityByName
1324 SCNetworkReachabilityGetFlags
1324
__SCNetworkReachabilityGetFlags
1324 getaddrinfo
1324 gai_lookupd
1324 _lookup_all
1324 _lookup_all_secure
1324 mach_msg
1324 mach_msg_trap
1324 mach_msg_trap
1 __spin_unlock
1 __spin_unlock
5 mach_msg
5 mach_msg_trap
5 mach_msg_trap
1330 Thread_6003
1330 _pthread_body
1330 __ape_agent
1330 __ape_internal
1330 mach_msg
1330 mach_msg_trap
1330 mach_msg_trap
1330 Thread_6103
1330 _pthread_body
1330 CMMConvTask(void*)
1330 pthreadSemaphoreWait(t_pthreadSemaphore*)
1330 _pthread_cond_wait
1330 semaphore_wait_signal_trap
1330 semaphore_wait_signal_trap
Total number in stack (recursive counted multiple, when >=5):
Sort by top of stack, same collapsed (when >= 5):
mach_msg_trap 2659
semaphore_wait_signal_trap 1330
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden