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




3rdparty/libprocess/src/subprocess_windows.cpp (lines 534 - 539)
<https://reviews.apache.org/r/46608/#comment194941>

    A few comments here.
    
    (1) I think we can simply this to:
    
    ```
    string env;
    foreach (const string& key, const string& value, environment.get()) {
      env += key + '=' + value + '\0';
    }
    ```
    
    then pass `env.data()` to `createChildProcess`.
    
    (2) Currently, if the string is larger than 32767 bytes, 
`createProcessEnvironment` returns `NULL`. We subsequently pass that result to 
`createChildProcess`, which result in the following behavior:
    
    > lpEnvironment [in, optional]
    A pointer to the environment block for the new process. If this parameter 
is NULL, the new process uses the environment of the calling process.
    
    Is this what we want? I think we can definitely incorporate whatever 
behavior we need if we go beyond the 32767 bytes, but I'm not sure exactly what 
behavior is expected here.


- Michael Park


On April 23, 2016, 11:41 p.m., Alex Clemmer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46608/
> -----------------------------------------------------------
> 
> (Updated April 23, 2016, 11:41 p.m.)
> 
> 
> Review request for mesos, Alex Naparu, Daniel Pravat, Artem Harutyunyan, 
> Joris Van Remoortere, Michael Park, M Lawindi, and Yi Sun.
> 
> 
> Bugs: MESOS-3637
>     https://issues.apache.org/jira/browse/MESOS-3637
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Libprocess: Implemented `subprocess_windows.cpp`.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/src/subprocess_windows.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46608/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Reply via email to