As the changes required to fix this will have implications for read and getmsg handling, I am deferring the fix until I have decent amount of time to work on it. That will be at least two weeks from now due to workload.
Thanks for the info,
Dave
At 02:28 PM 1/13/2003 Monday, Ragnar Paulson wrote:
Hi all,
We've looked at the sudden change of behaviour with regards to M_FLUSH messages further but aren't much further ahead. As near as I can tell from looking at LiS-2.13 and comparing it to LiS-2.15 the logic in the STREAM head has not changed at all.
Meanwhile our STREAMS are source code identical. They definitely haven't changed.
The drivers upper write put procedure processes many messages immediately. One message in particular causes the driver to
generate a M_FLUSH and an M_PCPROTO response. These are both queued to the driver upper read queue. The driver
upper read service routine does a putnext() to send the messages to the STREAM head. We do not do flush processing in
our service routine (to avoid flushing messages queued after the M_FLUSH).
In LiS-2.15 the STREAM head acts exactly as I would expect it to from reading the code ... it queues the messages in the lis_strrput() routine, and lis_strrsrv() flushes the read side queue, losing the M_PCPROTO. From code inspection I expect the same behaviour in LiS-2.13 (and LiS-2.14) but it doesn't happen.
Note I haven't attempted to debug the STREAM head in any case, our driver debug shows the messages being sent upstream via putnext, our application debug indicates the M_PCPROTO did not arrive. Naturally we don't think this is proper flsuh handling but I could listen to counter arguments. For now we're rearranging our drivers to try to avoid sending the M_FLUSH in this case and we're stymied as to why its worked up until now.
Regards,
Ragnar
We've just discovered that in LiS-2.15 (I haven't checked other versions but we've not seen this symptom before) the STREAM head put routine queues all messages (lis_strrput) including M_FLUSH. This causes the service routine to flush the stream head read queue of all messages that came before AND AFTER the M_FLUSH message was sent upstream.
Is this correct or desired behaviour? Shouldn't the lis_strrput process the M_FLUSH message immediately rather than defer it to the service routine?
_______________________________________________
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
