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 Fri, 14 Jul 2017 00:00:17 GMT


> On July 13, 2017, 12:27 a.m., James Peach wrote:
> > I think that a better approach is to define a static `UPID UPID::anonymous()` function
that returns a well-defined anonymous UPID for the system. Remove all the sending functions
that don't specify a `from` UPID and force them to explicitly pass the anonymous UPID. This
makes the used of anonymous message sends explicit which I think is preferable to this implicit
approach.
> 
> Jiang Yan Xu wrote:
>     Here's my thinking:
>     
>     - In libprocess the PID is usually not constructed directly, aside from being parsed
but that's also hidden from the users of the library. Users of libprocess tend to get the
PID from the process that owns that PID or from `spawn`. Afterwards it is used as an opaque
ID. Therefore I feel like more consistent with the current architecture to not expose it at
all. Having to know to use a speical ID is less straighfoward than calling a method that doesn't
take a `from` IMO.
>     
>     - Right now the PID is just a simple data struct and not guarded by a `process::initialize()`
call. This special UPID and PID uses the value of `__address__`, which initialized in `process::initialize()`.
Therefore even if we expose this anonymous / no sender PID directly, I feel it's probably
going to be constructed by something other than a static UPID method. This is a minor point
though.

* Anything that calls `post` is going to have to initialize `libprocess`, so initializing
`libprocess` when we generate the anonymous UPID seems OK too. `UPID process::anonymous()`.
* Sending anonymous messages is a special case, so it should be explicit. `post` is also a
special case since you already have to specify a target UPID. I argue that explicit is better
than implicit and 1 way to `post` is better than 2.


- James


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60821/#review180383
-----------------------------------------------------------


On July 13, 2017, 12:04 a.m., Jiang Yan Xu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60821/
> -----------------------------------------------------------
> 
> (Updated July 13, 2017, 12:04 a.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, James Peach, and Joseph Wu.
> 
> 
> Bugs: MESOS-7786
>     https://issues.apache.org/jira/browse/MESOS-7786
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> The immediate use of this is to fix MESOS-7753 but I feel this is a general concept that's
defined in similar systems (e.g., akka).
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/src/process.cpp b4d7791782a5d9e10fa44489057c8504d594bab2 
>   3rdparty/libprocess/src/tests/process_tests.cpp c6109547d04bd06e9395e4ec5f5130fd1500f9a0

> 
> 
> Diff: https://reviews.apache.org/r/60821/diff/1/
> 
> 
> Testing
> -------
> 
> make check.
> 
> 
> Thanks,
> 
> Jiang Yan Xu
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message