Hi, > status? The state of the operation is already gone, so you can't > distinguish between the caller giving you a bogus ID and the caller > giving you the ID of something that recently completed. The thread that > called test() assuming that the operation would be there will probably > be confused by the result either way. I was also talking about the interference between cancel and test calls. Right, you can't tell if the ID is bogus or recently completed if you run multiple test calls. However, I think that is much better than accessing invalid / undefined memory because that makes it hard to find the problem, in case you call test functions after another. Also the application knows if it has posted the ID before, so a return value like "completed or invalid ID" means something to the app. In terms of MPI multiple MPI_TEST calls of an already finished request return an error to the caller because the request is invalidated (set to MPI_REQUEST_NULL) once it is completed and mpi_test is called. That would be a similar semantics to trove with gen_safe. I like the explainations you write with poll and I agree if you call both test functions at the same time then it is bad practise / undefined which one gets the right status.
Julian _______________________________________________ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
