> On June 14, 2016, 2:40 p.m., Anand Mazumdar wrote: > > src/scheduler/scheduler.cpp, lines 484-490 > > <https://reviews.apache.org/r/48387/diff/3/?file=1417327#file1417327line484> > > > > hmm .. Why do you need to load the flags again here? You already did so > > on line L154, no? > > Jose Guilherme Vanz wrote: > The flag variable is initializated in constructor stack, right? I can not > access it from other function. Or... I'm missing something else around how > stout and libprocess handle the process.
My bad, looks like I jumped the gun here. I was referring to having `Flags` as a member variable and then accessing it directly here instead of loading it again here. This is similar to other places in the code that deal with `Flags` like the driver, master, agent etc. > On June 14, 2016, 2:40 p.m., Anand Mazumdar wrote: > > src/scheduler/scheduler.cpp, line 320 > > <https://reviews.apache.org/r/48387/diff/3/?file=1417327#file1417327line320> > > > > As per my review comment in an earlier version of the patch, let's have > > the signature of this method as: > > > > ```cpp > > void connect(const UUID& _connectionId); > > ``` > > > > And you can invoke this as: > > > > ```cpp > > process::delay(delay, self(), &MesosProcess::connect, > > connectionId.get()); > > ``` > > Jose Guilherme Vanz wrote: > Considering that Option's == operator already checks the content, uses > the UUID instead of Option<UUID> is a standart or just a prefererence in the > way to do stuff? ;D An `Option<T>` can wrap any `T`. If a reader see the argument of a function as `Option<T> arg`, it means that `arg` would either have a value of type `T` or would also have a `None()` in some scenarios. In this particular case though, `arg` would always be of type `UUID` and it can't ever be a `None`. This helps in readability and reasoning about code invariants/flow better. Makes sense? - Anand ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/48387/#review137507 ----------------------------------------------------------- On June 13, 2016, 11:20 p.m., Jose Guilherme Vanz wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/48387/ > ----------------------------------------------------------- > > (Updated June 13, 2016, 11:20 p.m.) > > > Review request for mesos, Anand Mazumdar, haosdent huang, and Vinod Kone. > > > Bugs: MESOS-5359 > https://issues.apache.org/jira/browse/MESOS-5359 > > > Repository: mesos > > > Description > ------- > > The scheduler library has been updated to wait a little deley before > initiate a connection with the master. The maximum amount of time waited > by the scheduler is defined by a flag: CONNECTION_DELAY_MAX. After > the master has been detected the scheduler picks a random delay that > can be between 0 and the CONNECTION_DELAY_MAX value. MESOS-5359 > > > Diffs > ----- > > src/scheduler/constants.hpp PRE-CREATION > src/scheduler/flags.hpp PRE-CREATION > src/scheduler/scheduler.cpp c79837c93e7329dbfa22e4288b44237f33408ba9 > > Diff: https://reviews.apache.org/r/48387/diff/ > > > Testing > ------- > > > Thanks, > > Jose Guilherme Vanz > >
