RE: socket problem

Are these blocking or non-blocking sockets?

If they're non-blocking, is it possible that the select() is returning
immediately, even if theres no data to read?  This would cause it to loop
from select() to read(), etc, taking up lots of CPU.

the most common cause I've seen for this is specifying a write or
exception descriptor set to select() in addition to a read, when that's
not really what the programmer meant to do.  Because a set of write
descriptors was given, and because there's still space in the write
buffer, select() always returns immediately.    Since you're only trying
to read from it, it loops and wastes CPU.

I'd recomment running the program in debug, and seeing exactly what
it's doing.   If it's truly stopping at the select() call, then it
shouldn't be using CPU, it should sit at "SELW" status.

If nothing else works, post the relevant section of code to this list,
and I'll see if a problem jumps out at me :)


On Thu, 20 Dec 2001, Tom Daly wrote:
>
> Hi all,
>
> My socket server is having this weird problem at one of our customer sites.
> Whenever the program gets to the select() the CPU% cranks up to 15%-18%.
> What I don't understand is why it only happens on this one 400, other
> customers typically run around 1%-2%.
>
> The program sends a request for data to the partner pgm and then does
> select().  If FD_SET indicates there is data available the program does a
> read().  The program loops on the select() & read() until an 'end or record'
> string is encountered at which point the program spits the data out to a
> dtaq and then sends the next request for data to the partner program.  The
> parnter program doesn't push data at the RPG socket pgm until a record is
> requested... the RPG polls the partner.
>
> So why does select() suck up so much CPU and how can it be fixed?  Any
> ideas?
>