select(2) call

[Craig Hilsenrath]

I am developing a program that is designed to act as a generic routing
daemon. This process opens a unix domain stream socket and listens for
connections. Two types of clients are supported, producers, and consumers.
The producers have the ability to produce data faster than the consumers
can process it. So the routing daemon (routed) has the ability to queue
messages bound for a consumer. 

I have implemented the following simple test set. 

routed creates it's socket, listens, issues the select(2) call and waits. 

Using dbx I execute a consumer. The consumer issues a connect(2) call.
When the connect(2) call returns routed has reported that the connection
was accepted AND that the new socket is ready for writing (select has
returned twice) ?????  routed remembers via an internal flag that the
consumer is ready for input and stops "select"ing on that descriptor.  I
have yet to issue a read(2) through the consumer. When I do issue the
read(2) from the consumer the call blocks. This I expect because no data
has been sent to the consumer from routed.  However, the read does cause
select to return. I suspect this is a side effect of the connection
anomoly. 

Next I run a test producer. The producer connects and again routed has
reported that the connection was accepted AND that the new socket is ready
for writing (?). The producer has yet to write anything because it is
waiting for input from standard in.  When the producer writes, the string
is passed along to the consumer and printed on its standard out.
Everything seems to be working except for the anomolies stated above so I
go on.

In order to test the queuing capabilities of routed I put some phony work
in the consumer.  This work merely consists of a for loop counting to
10,000,000 before issuing another read call. After writing to the consumer
routed toggles the busy flag for the consumer and again "select"s on the
consumer. select(2) returns imediatlely with the consumers write bit set
even though the consumer is busy counting to 10,000,000. I know this
because dbx has not finished "next"ing through "for(i=0; i < 10000000;
++i) ;". As I continue to produce data routed sends it along without fail.
The consumer misses many of the messages intended for it.

Any help on this at all would be greatly appreciated. My managers are
afraid of IPC to begin with. I had to bend some arms to be allowed to
develop this seemingly simple test set. It only took three days to develop
the test code, but I have spent another three days trying to work out this
bug. I am at my wit's end.

Send mail to coh at gcm.com or call (203) 625-2764 and ask for Craig.