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
