Xref: utzoo comp.sys.hp:6123 comp.unix.internals:171
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!samsung!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!liuida!isy!staffan
From: staffan@isy.liu.se (Staffan Bergstrom)
Newsgroups: comp.sys.hp,comp.unix.internals
Subject: Re: hp-ux 7.0/800 select() strangeness?
Message-ID: <1990Sep3.135920.13525@isy.liu.se>
Date: 3 Sep 90 13:59:20 GMT
References: <90242.151955MAH@awiwuw11.wu-wien.ac.at>
Organization: Dept of EE, University of Linkoping
Lines: 30

MAH@awiwuw11.wu-wien.ac.at (Michael Haberler) writes:

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

-
-
-

>Has anybody else encountered this behaviour? Is this a bug? If so, is there
>a workaround?

>- michael

I have had similar problems but it turned out to be the macros
FD_SET, FD_CLR etc, that was the cause of the problem. 
FD_SET is defined as follows.
#define FD_SET(n, p)    ((p)->fds_bits[(n)/NFDBITS] |= (1 << ((n) % NFDBITS)))
One has to be carful when using them on closed files otherwise 
it could cause an atempt to do a negative shift.
I had a program that worked fine on sun3, sun4 and hp300 (hp-ux 7.0),
but did not work at all on when I tried to port it to hp 800, because of this.

/Staffan