tight loop on select/ioctl on X socket under certain conditions - HP UX

This is a discussion on tight loop on select/ioctl on X socket under certain conditions - HP UX ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: tight loop on select/ioctl on X socket under certain conditions

  1. tight loop on select/ioctl on X socket under certain conditions

    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

    I'm interpreting the 4 to be file descriptor 4, which lsof shows as:
    tmrs.new 8770 jko 2u STR 157,0x2 0t2875121 1410
    /dev/pts/2->ldterm->ptem->pts
    tmrs.new 8770 jko 3w REG 64,0x5 1856705 1858
    /tmp/tusc.out
    tmrs.new 8770 jko 4u inet 0x44714b80 0t139484 TCP
    tobi:49984->tobi:6002 (ESTABLISHED)
    tmrs.new 8770 jko 5r FIFO 0x43ffdd08 0t0 423332
    tmrs.new 8770 jko 6w FIFO 0x43ffdd08 0t0 423332

    I've also noticed that when run in the foreground, I can "stop" the
    tusc/truss output when I grab the window with a mouse-click and the
    output from it is suspended until I release the mouse.

    I've also used HPUX's glance/gpm to see the high cpu usage due to those
    system calls and used the tusc -C option to get a summary, confirming a
    large number of select/ioctl/gettimeofday calls


  2. Re: tight loop on select/ioctl on X socket under certain conditions

    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...

  3. Re: tight loop on select/ioctl on X socket under certain conditions

    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...



  4. Re: tight loop on select/ioctl on X socket under certain conditions

    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


  5. Re: tight loop on select/ioctl - problem solved

    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


  6. Re: tight loop on select/ioctl - problem solved

    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...

+ Reply to Thread