John.K.D.Ko@gmail.com wrote:
> I'm using tusc/truss to trace system calls of my program on HPUX11.11
> and it appears that it gets caught in a select loop trying to read from
> a file descriptor. I've got 2 scenarios where in the first instance,
> there seems to be a pause/sleeping on the select call (and a reasonable
> number of events) and another where it just goes crazy. Can someone
> please tell me if I'm interpreting the output correctly and offer
> suggestions as to how to proceed?

> I'm getting these by the tens of thousands.
> select(17, 0x7f7f0c54, 0x7f7f0d54, 0x7f7f0e54, 0x7f7f0c48) = 0
> gettimeofday(0x7f7f0b80, NULL) ........................... = 0
> ioctl(4, FIONREAD, 0x7f7f0bc0) ........................... = 0
> ioctl(4, FIONREAD, 0x7f7f0bc0) ........................... = 0
> select(17, 0x7f7f0c54, 0x7f7f0d54, 0x7f7f0e54, 0x7f7f0c48) = 0
> gettimeofday(0x7f7f0b80, NULL) ........................... = 0
> ioctl(4, FIONREAD, 0x7f7f0bc0) ........................... = 0

It would be good to see the arguments being passed to select() - in
particular the timeout settings. So, add a -v to the tusc options to
get verbose output.

BTW, make sure you have the latest tusc - either from (IIRC)
devresource.hp.com or from ftp.cup.hp.com/dist/networking/tools/

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Thanks Rick. I've confimed that I have the latest tusc version as
found at
http://hpux.connect.org.uk/hppd/cgi-...ge=&term=/tusc
$ tusc -V
tusc: version 7.8, 2005/08/09, Copyright (c) 1996-2005 Chris Bertin
(HP).

and it looks like the timeout setting is very low already so something
about my different parameters is causing it to have an immediately
expired timer every time it comes back to search for more data.

I believe the timeout is set a 2 seconds and all subsequent calls
cascading in my second scenario. Does this mean I should be going down
to the base libraries that call this to change the timeout?
XtAppMainLoop I thought - I don't know how to do that...

>From 1st scenario where CPU not in a busy loop:
timeout.tv_sec: 0
timeout.tv_usec: 0
timeout.tv_sec: 0
timeout.tv_usec: 0
timeout.tv_sec: 0
timeout.tv_usec: 902386
timeout.tv_sec: 0
timeout.tv_usec: 0
timeout.tv_sec: 0
timeout.tv_usec: 0
timeout.tv_sec: 0
timeout.tv_usec: 741601
timeout.tv_sec: 0
timeout.tv_usec: 0
timeout.tv_sec: 0
timeout.tv_usec: 470834
timeout.tv_sec: 2
timeout.tv_usec: 0

>From problematic scenario:
timeout.tv_sec: 0
timeout.tv_usec: 0
timeout.tv_sec: 0
timeout.tv_usec: 0
timeout.tv_sec: 0

Rick Jones wrote:
> John.K.D.Ko@gmail.com wrote:
> > I'm using tusc/truss to trace system calls of my program on HPUX11.11
> > and it appears that it gets caught in a select loop trying to read from
> > a file descriptor. I've got 2 scenarios where in the first instance,
> > there seems to be a pause/sleeping on the select call (and a reasonable
> > number of events) and another where it just goes crazy. Can someone
> > please tell me if I'm interpreting the output correctly and offer
> > suggestions as to how to proceed?
>
> > I'm getting these by the tens of thousands.
> > select(17, 0x7f7f0c54, 0x7f7f0d54, 0x7f7f0e54, 0x7f7f0c48) = 0
> > gettimeofday(0x7f7f0b80, NULL) ........................... = 0
> > ioctl(4, FIONREAD, 0x7f7f0bc0) ........................... = 0
> > ioctl(4, FIONREAD, 0x7f7f0bc0) ........................... = 0
> > select(17, 0x7f7f0c54, 0x7f7f0d54, 0x7f7f0e54, 0x7f7f0c48) = 0
> > gettimeofday(0x7f7f0b80, NULL) ........................... = 0
> > ioctl(4, FIONREAD, 0x7f7f0bc0) ........................... = 0
>
> It would be good to see the arguments being passed to select() - in
> particular the timeout settings. So, add a -v to the tusc options to
> get verbose output.
>
> BTW, make sure you have the latest tusc - either from (IIRC)
> devresource.hp.com or from ftp.cup.hp.com/dist/networking/tools/
>
> rick jones
> --
> oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
> these opinions are mine, all mine; HP might not want them anyway...
> feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Doh! I forgot to show a snippet of the output related to the
problematic area. No file descriptors or just no data?? 1st scenario
processes inputs from one other process (though multiple processes
report events) while the second scenario may process events from
multiple processes instead of just throwing it away early. I don't
know if this is affecting the overall xt timeout.
select(17, 0x7f7f0c54, 0x7f7f0d54, 0x7f7f0e54, 0x7f7f0c48) = 0
nfds: 17
readfds: EMPTY
writefds: EMPTY
errorfds: EMPTY
timeout.tv_sec: 0
timeout.tv_usec: 0
gettimeofday(0x7f7f0b80, NULL) ........................... = 0
ioctl(4, FIONREAD, 0x7f7f0bc0) ........................... = 0
command: _IOR('f', 127, 4)
data: 0
ioctl(4, FIONREAD, 0x7f7f0bc0) ........................... = 0
command: _IOR('f', 127, 4)
data: 0
select(17, 0x7f7f0c54, 0x7f7f0d54, 0x7f7f0e54, 0x7f7f0c48) = 0
nfds: 17
readfds: EMPTY
writefds: EMPTY
errorfds: EMPTY
timeout.tv_sec: 0
timeout.tv_usec: 0
gettimeofday(0x7f7f0b80, NULL) ........................... = 0
ioctl(4, FIONREAD, 0x7f7f0bc0) ........................... = 0
command: _IOR('f', 127, 4)
data: 0

Thanks again for your help. After reading various things on internet
about XtAppMainLoop and issues with XtAppAddWorkProc and
XtAppAddTimeout, I found some offending code that when removed, seems
to eliminate the problem.

John

John.K.D.Ko@gmail.com wrote:
> Thanks again for your help. After reading various things on internet
> about XtAppMainLoop and issues with XtAppAddWorkProc and
> XtAppAddTimeout, I found some offending code that when removed, seems
> to eliminate the problem.

Excellent! I always get a kick out of successfully helping people with
problems in areas with which I have no direct experience (eg X)
(Although my desires for netperf4 are such that I'll need to learn
GTK+, and/or find folks with spare cycles)

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...