Re: long poll() delay

[Richard Frith-Macdonald]

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.