mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: Review Request 60821: Introduced a "no sender" UPID.
Date Wed, 19 Jul 2017 01:01:22 GMT

> On July 17th, 2017, 2:14 p.m. PDT, Jiang Yan Xu wrote:
> 
> Clarified with Joseph offline. The proposal is to just fix this specific situation in
MESOS-7753 (I submitted /r/60917/ for review). I'll drop this review for now and we can revisit
this when we have another use case.
> While I dropped this for now, here I'd like to summarize the discussion.
> So the discussion is around how to make these process::post methods less error-prone:
> // post(1)
> void post(const UPID& to,
>           const std::string& name,
>           const char* data = nullptr,
>           size_t length = 0);
> 
> // post(2)
> void post(const UPID& from,
>           const UPID& to,
>           const std::string& name,
>           const char* data = nullptr,
>           size_t length = 0);
> 
> 
> Given post(1) may be confused with send, which most Mesos "production" code uses:
>   void send(
>       const UPID& to,
>       const std::string& name,
>       const char* data = nullptr,
>       size_t length = 0);
> 
> 
> We can either a) eliminate post(1) and do
> post(UPID::anonymous(), to, data);
> 
> or b) hide the implementation under post(1) so you would do:
> post(to, data);
> 
> 
> Explicitness is good and at this point I am not preferring b) over a), but just would
like to explore whether either is a good enough fix.
> Consider:
> 
> 	• Even if we eliminate post(2), is post(2) good enough? Should we put it in a different
namespace to prevent misuse (currently most uses of either post are in tests)?

No, I already struggle to find symbols in the forest of namespaces.

> 	• What's going to prevent the caller from doing post(UPID(), to, data), is Try<Nothing>
post(from, to, data) with validation going to help?

Maybe there's no good use case for an empty UPID? Alternatively `post` could `CHECK` the UPID?

> 	• Could UPID::anonymous() be misused for some unintented purposes?
> 	• If we use a different method name for post(1), something like noSenderPost(to, data)
(I am sure we can come up with a better name), is it still confusing?

If `post` for when you send a message without a process. Maybe the right approach is to remove
post(2) and define post(1) to always use the anonymous sender?

> 	• Finally, is any of these better than clearly document the APIs with caution notes
about empty UPIDs?

Usually I refer to Rusty Russell' API levels. If we can make the API impossible to misuse
or throw a runtime or compile time error, that's better than simply documenting the traps.

J
Mime
View raw message