Needless to say (for the nth time :-) ) that changing this bit of code makes me
nervous. However, it occurred to me that there is a much better way to test
this code than setting up an environment that generates some out of order
events with out us being able to specify the order.
Since this routine is executed serially, it should be sufficient to set up a test
code that would simulate any out-of-order scenario we want. If one specifies
number of “messages” to be “sent”, and “randomly” changes the order they
arrive (e.g. scramble some input vector), one can check and see if the messages
are “received” in the correct order. One could even “drop” messages and see
if matching stops. Using a test code like this, and a code coverage tool, one
should be able to get much better testing that we have to date.
What would you think about doing something like this ? Seems like a few hours
of this sort of simulation would be much better than even years of testing and
relying on random fluctuations in the run to thoroughly test out-of-order scenarios.
What do you think ?
On 12/17/07 8:32 AM, "Gleb Natapov" <email@example.com> wrote:
On Thu, Dec 13, 2007 at 08:04:21PM -0500, Richard Graham wrote:
> Yes, should be a bit more clear. Need an independent way to verify that
> data is matched
> in the correct order – sending this information as payload is one way to do
> this. So,
> sending unique data in every message, and making sure that it arrives in
> the user buffers
> in the expected order is a way to do this.
Did that. Encoded sequence number in a payload and sent many eager
packets from one rank to another. Many packets were reoredered, but
application received everything in a correct order.
devel mailing list