I think I see a way that something like this might happen due to a bug in the stream head read side flushing code. I will go ahead and fix it even it it is not your case.
-- Dave
At 12:50 PM 12/18/2002 Wednesday, Howard Selover wrote:
Hello Dave,
There are still problems with LiS-2.14.L. I can cause the read side stream to hang. It appears that message byte count accounting is not being performed correctly.
When my test fails, I find the following conditions. The stream head has no messages in the streams queue. There are 48 344 byte messages in the special streams head message list, a total of 16512 bytes. The stream head q_count field is set to 66640 and the high water mark is set to 65535. The streamhead q_flag is set to 0x87d.
The write direction seems to be working in the very short period of time I have tried it.
--
Howard Selover III
Principal Engineer
Chief Architect's Office
Ulticom, Inc.
1020 Briggs Road
Mount Laurel, NJ 08054
Direct: +1-856-787-2739
Mobile: +1-856-495-4181
Fax: +1-856-866-2033
Email: [EMAIL PROTECTED]
Web: www.ulticom.com
_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
