Re: Style guide for std::move
Also, do we want to allow a re-assignment after a move to re-use the object?
Just some food for thought, have you explored extending Option to capture
this?
Optionvectorint v {1, 2, 3, 4};
foo(v.move());
v.isSome(); // false
v = {1, 2, 3, 4};
v.isSome() // true
On Wed, Jun 17, 2015 at 7:19 AM, Till Toenshoff toensh...@me.com wrote:
+1 for 1. “treat it like a deleted pointer”
On Jun 12, 2015, at 4:21 PM, Alexander Rojas alexan...@mesosphere.io
wrote:
Hey guys, there have been questions on how to deal with std::move in the
code. Right now our style guide says nothing about it, but there is no
consensus in the reviews. The problem with std::move is that for all
standard library functions that accept rvalue references as parameters are
guaranteed to leave the moved object in a valid but unspecified state (see
http://en.cppreference.com/w/cpp/utility/move
http://en.cppreference.com/w/cpp/utility/move).
The following are some ideas into how to deal with moved objects
1. Treat std::move as a delete and stop using it after the move
std::vectorint v{1, 2, 3, 4};
..,
foo(std::move(v)); // Don’t use
2. Always create explicitly an scope the object to be moved, with the
first line being the definition of the object to be moved, and the last
line of the scope the move itself.
if (bar()) {
{
std::vectorint v{1, 2, 3};
….
foo(std::move(v));
}
}
3. Create a scope for the if no scope already exists following the rules
of 2):
if (bar()) {
std::vectorint v{1, 2, 3};
….
foo(std::move(v));
}
Re: Enabling 'network' namespace for custom network isolators
Hi All, I have now filed a Jira ticket (MESOS-2884)[1] and created a couple of RRs[2] along the lines of the suggestions provided by Ian and Jie. There is one difference though. Instead of creating a LinuxIsolator class, I added the `int namespaces()` directly to Isolator class. By default, it returns '0' and thus allows for a simplified approach. By creating LinuxIsolator, we would then have a complicated lookup logic in MesosContainerizer to first figure out the subclass type and then call namespaces() on it. From here on, I think we can continue the discussion on the Jira ticket if no one has any objections. Best, Kapil [1]. https://issues.apache.org/jira/browse/MESOS-2884 [2a]. https://reviews.apache.org/r/35585/ [2b]. https://reviews.apache.org/r/35586/ On Mon, May 11, 2015 at 7:42 PM, Niklas Nielsen nik...@mesosphere.io wrote: (inlined) On 11 May 2015 at 14:30, Kapil Arya ka...@mesosphere.io wrote: On Mon, May 11, 2015 at 4:58 PM, Jie Yu yujie@gmail.com wrote: Yes. The simplest (cleanest?) way that I see would be to refactor the launcher to take the desired flags when executing the executor, i.e., (Linux)Launcher::fork() takes the namespace flags. The launcher would be directed which namespaces to create by the caller, not inferring them itself from any flags: the MesosContainerizer in turn would determine this based on the isolators it was using for the container (querying them). This also facilitates the MesosContainerizer having different isolators, and thus namespaces, for different containers. +1 For instance, the isolator could have an interface 'int namespaces()' which specifies the namespaces needed. The launcher can just query that and pass them to the linux launcher. Since currently, the launcher and isolator interfaces are designed for both mac and linux and namespace does not make sense on Mac, we probably need a LinuxIsolator interface (inherit from Isolator) and a LinuxLauncher interface (inherit from Launcher). This is a good idea. I think this will keep things pretty clean and readable within Mesos and for the Isolators. - Jie On Mon, May 11, 2015 at 1:29 PM, Ian Downes idow...@twitter.com.invalid wrote: TLDR: We want to use a custom network isolator, but there is no way to enable the 'network' namespace from within an isolator module. We are working on creating a custom network isolator as a Mesos module. However, the way Mesos Slave is setup, there is no way to enable 'network' namespace for the executor without enabling the 'port-mapping' isolator. This is due to the fact that the LinuxLauncher looks at the '--isolation' flag to figure out the list of namespaces to be enabled. The same problem would exist if one were to write a custom pid or filesystem isolation module. Curious, are these going to be open source and added to the codebase or will they be proprietary modules? What specifically is lacking in the existing network and pid isolators? Could we extend those? We will be bringing in a dependency, experimental work with Calico, and wanted to be flexible in how we call out to our tools. So, there are a couple of question: 1. With the current Mesos source code, is there a way to specify the 'network/port_mapping' isolator in a way that it doesn't do the actual work of mapping the ports (e.g., without specifying any port-mapping specific flags)? If this works, we can just specify this isolator on the slave command line and it would force the LinuxLauncher to create a new network namespace. No, as written they're coupled. 2. Is it reasonable to have a separate mechanism to specify what namespaces should be created/enabled for an executor if we don't want to use the in-built isolators such as pid and port-mapping? Yes. The simplest (cleanest?) way that I see would be to refactor the launcher to take the desired flags when executing the executor, i.e., (Linux)Launcher::fork() takes the namespace flags. The launcher would be directed which namespaces to create by the caller, not inferring them itself from any flags: the MesosContainerizer in turn would determine this based on the isolators it was using for the container (querying them). This also facilitates the MesosContainerizer having different isolators, and thus namespaces, for different containers. WRT (2), one potential mechanism is to introduce a new flag, '--namespace'. The downside of creating such a low-level flag is that it provides little to no value to the end users. The end users shouldn't be concerned about which namespaces to enable and so on That seems unduly onerous to the user and
Re: Style guide for std::move
+1 for 1. “treat it like a deleted pointer”
On Jun 12, 2015, at 4:21 PM, Alexander Rojas alexan...@mesosphere.io wrote:
Hey guys, there have been questions on how to deal with std::move in the
code. Right now our style guide says nothing about it, but there is no
consensus in the reviews. The problem with std::move is that for all standard
library functions that accept rvalue references as parameters are guaranteed
to leave the moved object in a valid but unspecified state (see
http://en.cppreference.com/w/cpp/utility/move
http://en.cppreference.com/w/cpp/utility/move).
The following are some ideas into how to deal with moved objects
1. Treat std::move as a delete and stop using it after the move
std::vectorint v{1, 2, 3, 4};
..,
foo(std::move(v)); // Don’t use
2. Always create explicitly an scope the object to be moved, with the first
line being the definition of the object to be moved, and the last line of the
scope the move itself.
if (bar()) {
{
std::vectorint v{1, 2, 3};
….
foo(std::move(v));
}
}
3. Create a scope for the if no scope already exists following the rules of
2):
if (bar()) {
std::vectorint v{1, 2, 3};
….
foo(std::move(v));
}
[GitHub] mesos pull request: fixed broken 404 doc link for torque on mesos
GitHub user kensipe opened a pull request: https://github.com/apache/mesos/pull/46 fixed broken 404 doc link for torque on mesos It is unclear if Torque is an active project... I can remove the torque docs if it is preferred. However the doc links for torque resulted in a 404 and this PR fixes that issue with a relevant link. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kensipe/mesos torque-doc-update Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mesos/pull/46.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #46 commit 6b9421b88c8bc938b7f347d6a449ff7c95bb7e6f Author: Ken Sipe kens...@gmail.com Date: 2015-06-17T14:18:42Z fixed broken 404 doc link for torque on mesos --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Question about Libprocess and Lithe
Hi 宗志, i suggest you reference a paper: Lithe: Enabling Efficient Composition of Parallel Libraries 2015-06-11 20:09 GMT+08:00 baotiao baot...@gmail.com: Hi People I am interested in libproces, and we know libprocess was wrote according Lithe. I have some questions about the theory Lithe 1. can you tell me the advantage of Lithe. 2. the relation of lithe and libprocess. I find libprocess is a Reactor model. libprocess is same as Erlang. When we start libprocess, we will start 8 OS thread, the the process in libprocess is just a task in thread. Is it lithe do the same job as libprocess? Or lithe optimize the model Thanks 陈宗志 Blog: baotiao.github.io -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com
