mpmilano
commented
4 years ago I definitely see the reason you'd want to have specific endpoints behave as only P2P or only ordered, but I'm not sure what the exact functor proposal is. Right now each subgroup-backing class may register any number of methods as remote invocation targets. It would be straightforward enough to, at the point of registration, ask the programmer to specify whether a particular method should be invocable only P2P, only ordered, or both.
Is the purpose behind this proposal entirely motivated by the need to differentiate send targets? If so, this would have the desired effect and be the easier change to make.
KenBirman
etremel
songweijia
A functor object is simply a C++ object that defines some standard upcall API, such as "invoke". These objects can have names, be templated, etc. So, in all ways, they can be used like methods. I want to suggest that in Derecho V 2.1 we switch to registering upcalls in our Derecho groups as functors rather than as methods.
This responds to an issue Weijia has run into several times now with new developers using Derecho/Cascade: they get confused and do p2p calls to endpoints intended as multicast endpoints, or vice versa. We have that issue because in Derecho, endpoints are identified by tags, which are than associated to the upcall method, but there is no compile time or runtime way to check that the endpoint type is actually compatible with the form of operation that was done. In V2.1 I want to unify everything under a single derecho::send API, but that will just make this kind of mistake even more likely.
If we switch to a functor model, we can offer two preexisting interface classes, both defining "invoke". One class would be derecho::p2p, and the other class, derecho::multicast. But because this provides us with the ability to define instance-specific constants, we would then have an easily accessible form of "endpoint type" information that can be accessed both at compile time or, if needed, at runtime. In fact I think the compile-time check this would enable might actually be adequate: I am thinking that I might be able to generate a constexpr table that can be indexed by endpoint tag, and would return the endpoint type. Then my generic send would have a compile time (templated) bit of logic asserting that the type is compatible with the invocation pattern (this derecho::send will be overloaded and just by the number of arguments, I can tell if it is a p2p operation or a multicast: the target of a p2p operation needs to be a specific member of a designated shard; the multicast version just specifies the shard, or omits it in which case "this" shard will be the target). Even if I can't do this via a constexpr table, we can easily test when a derecho::send is issued (and then no need to test again on delivery, since no illegal deliveries could occur!)
Does anyone see any issues with this? We can deprecate the old style of registering a method, but still support it, and then eliminate it entirely whenever we do a v3.0 release down the road.