[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: long poll() delay
From: |
Richard Frith-Macdonald |
Subject: |
Re: long poll() delay |
Date: |
Wed, 29 May 2002 14:48:45 +0100 |
On Wednesday, May 29, 2002, at 02:39 PM, Stefan Urbanek wrote:
Richard Frith-Macdonald wrote:
I'd suggest running the app under strace to log system calls, and see
what
the poll is waiting for.
Output from strace (with -rTv options) between the first two poll
NSLogs:
0.000920 write(2, "2002-05-29 15:32:17.547 Farmer[1"..., 49) = 49
<0.000278>
0.000659 poll([{fd=4, events=POLLOUT}], 1, 18358) = 0 <18.368170>
18.388649 getpid() = 18432 <0.000007>
0.000112 gettimeofday({1022679155, 937848}, NULL) = 0 <0.000007>
0.000426 write(2, "2002-05-29 15:32:35.937 Farmer[1"..., 47) = 47
<0.000265>
What more information is necessary to trace where the problem is?
More context ... we know it's polling on fd 4, but we don't know what
fd 4
is and what has been done to it. My guess is that it's a socket on which
an async connect attempt has been initiated to talk to gdomap.
My guess is it's trying to contact gdomap on the remote host, and the
connection attempt is taking a while to time out rather than failing
instantly.
Only after failing to find the required server on the remote host will
it attempt to talk to an alternative on the local host.
I do not understand, why it is trying to contact gdomap on the remote
host? Everything is being run on the same host, only the X serer
(display) is remote (in relation to the application).
Because it's displaying on a remote host ... so it knows it needs to talk
to the distributed notification center and pasteboard server for that
host.
The default assumption is that they will be running on that host, so it
needs to ask gdomap on that host for the IP port numbers on which they
can be reached.
Only if it can't find them there will it look for them elsewhere on the
network.
Perhaps it might be worth adding a default to reverse the order in which
the system looks for these servers, or alternatively using a shorter
timeout.