MAH@awiwuw11.wu-wien.ac.at (Michael Haberler) (08/30/90)
I have encountered a strange behaviour of several programs which use select(2) on hp-ux 7.0 on the Series 800. All of these programs are 'ported' BSD code, so I have the suspicion there's something in common: It seems that programs which have select(2) in their inner loop sometimes start using enormous amounts of system cpu time, just as if the select() call would return immediately as if it were polling. Among those programs are Xemacs 18.55, Greg Minshall's tn3270, and named4.8.3. Xemacs tends to do this especially if the X server terminates before emacs. I did'nt find a explanation for named behaviour. With tn3270, it looks like a modem disconnect and thus eof on the tty would cause tn3270 looping. tn3270 seems to spend it's time in select() itself, while named returns to user mode and immediately calls select again. One can see this when attaching the process in question to the debugger (xdp -P <pid> <program>). Since several programs show this behaviour, I suspect it has to do with the way select() is implemented in hpux 7.0. Has anybody else encountered this behaviour? Is this a bug? If so, is there a workaround? - michael
joana@hp-vcd.HP.COM (Joan Armstrong) (09/01/90)
Michael Haberler reports: >I have encountered a strange behaviour of several programs which use >select(2) on hp-ux 7.0 on the Series 800. All of these programs are >'ported' BSD code, so I have the suspicion there's something in common: > >It seems that programs which have select(2) in their inner loop sometimes >start using enormous amounts of system cpu time, just as if the select() >call would return immediately as if it were polling. Among those programs >are Xemacs 18.55, Greg Minshall's tn3270, and named4.8.3. > >Since several programs show this behaviour, I suspect it has to do with the >way select() is implemented in hpux 7.0. > >Has anybody else encountered this behaviour? Is this a bug? If so, is there >a workaround? We noticed this when upgrading to HP-UX 6.5 (same in 7.0) ... our situation involves a realtime control program using a select to read pipe variables. If the specified pipe was not writing, the select would fall thru, effectively polling. Yucky. Our fix is not generic, but we just check to see that all the select'ed pipes are indeed alive. Sorry, this fix probably isn't much help. --Joan HP Vancouver Division