> A way to solve this would be to have a transaction identifier
> into each
> object descriptor, that is incremented each time the object's
> state is altered (e.g. removal/insertion of some element
> from/to the
> pendq and so on).
> This works as long as the object descriptor itself can _not_ be
> deleted in the mean time.
> IOW, "object->current_rev != prev_rev" makes sense only if "object"
> remains to be valid.
This is the purpose of revalidating the object, step 6a.
arghh.. I missed 6a as I was looking at Jan's code and applied it to other cases "as is".
And the register would be a source of information on this step.
This whole discussion makes me think that if we want to go down the path
of providing a generally safe and latency-aware support for the /proc
routines, we should definitely define some common mechanisms to
implement them, typically in the registry code.
Yep. Actually, the register may likely do both 6a and 6b steps. e.g. a revalidation descriptor is stored in "xnobject" and something like xnregister_object_changed(handle) should be called when the object's internal state changes... just the very first idea and maybe not the best one.
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core