> Our problem is an application hanging on a call to 'getmsg'.
> We have some home-grown Streams modules providing
> formatting and message content verfication. 'select' is used
> to indicate to the application of the availability of data on
> one or more devices...we go to get data from the identified
> device and the process hangs....
> We are also witnessing 'select' not returning an indication
> of data available when it should. The problem occurs
> infrequently but on a system that should run unattended.
> We have had some systems running for literally months with no
> problems and then another system will hang 2 or 3 times in
> a day...
> Anyone else see something similar? Problem appears to be
> associated with overall system load....
<some text deleted>
I received 3 replies, one of which was a request for the
summary...since this was my first post I was grateful not
to receive any flames :-)
John Howie <firstname.lastname@example.org> sent
> Answer: Don't use select - use poll(2) instead.
> It is more hassle but at least
> it works. The Stream head doesn't work to well
> with select so you find it
> saying that there is data available when there isn't
> and so your process blocks
> on a subsequent read waiting for data.
This is something that has been planned for some time...
Henrik Martin <Henrik.Martin@eua.ericsson.se> suggested I
check the Streams module was handling flow control correctly.
....we seemed OK on this front.
In the end we moved to use of poll and installed 100359-06,
the latest Jumbo Streams patch.
Point of interest:- comparing two systems, one using
poll, the other select, the process using poll had a
reduced cpu load...by around 30%.
Given the nature of the problem I can't say it is fixed
yet. I will post again should anything conclusive turn up.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:28 CDT