> On April 5, 2018, 4:07 p.m., Akash Gupta wrote: > > 3rdparty/stout/include/stout/os/windows/mktemp.hpp > > Line 54 (original), 54 (patched) > > <https://reviews.apache.org/r/66424/diff/1/?file=1992243#file1992243line54> > > > > Huh that's a strange function. Seems like it can cause time check/use > > race conditions. We probably want to replace this with the native temp > > directory functions in the future.
Ha, I agree. It's listed in MESOS-8682 so it'll get done eventually. > On April 5, 2018, 4:07 p.m., Akash Gupta wrote: > > 3rdparty/stout/include/stout/os/windows/open.hpp > > Lines 37 (patched) > > <https://reviews.apache.org/r/66424/diff/1/?file=1992244#file1992244line40> > > > > I *think* FILE_FLAG_WRITE_THROUGH == O_SYNC. It's... similar, but I looked at the use-cases and I think we're more likely to introduce unintended behaior by trying to guess what the user wants here. > On April 5, 2018, 4:07 p.m., Akash Gupta wrote: > > 3rdparty/stout/include/stout/os/windows/open.hpp > > Lines 45 (patched) > > <https://reviews.apache.org/r/66424/diff/1/?file=1992244#file1992244line48> > > > > I believe the default behavior(`SECURITY_ATTRIBUTES == NULL`) is to > > inherit from the parent directory / access token. We should ask around on > > what's the proper settings for security. Don't let me forget to file/update/mention the permissions issue. > On April 5, 2018, 4:07 p.m., Akash Gupta wrote: > > 3rdparty/stout/include/stout/os/windows/open.hpp > > Lines 61 (patched) > > <https://reviews.apache.org/r/66424/diff/1/?file=1992244#file1992244line64> > > > > It's up to you, but I find it clearer to have a switch statement on the > > bitfields like this: > > ``` > > switch(oflag & (O_RDONLY | O_WRONLY | O_RDWR)) { > > case O_RDONLY: > > case O_WRONLY: > > case O_RDWR: > > default: > > } > > ``` Only problem is that O_RDONLY is 0, so case O_RDONLY will never execute. Some brilliant programmer somewhere though that 0 would work great as a bit flag. > On April 5, 2018, 4:07 p.m., Akash Gupta wrote: > > 3rdparty/stout/include/stout/os/windows/open.hpp > > Lines 73 (patched) > > <https://reviews.apache.org/r/66424/diff/1/?file=1992244#file1992244line76> > > > > Same thing as above. I think it's more import on this one because > > there's techically 8 cases for `O_CREAT`, `O_EXCL`, `O_TRUNC`, but POSIX > > and Windows only have defined behavior for 5 of them, so you can explicitly > > mention the undefined behavior cases like this: > > > > ``` > > switch(oflag & (O_CREAT | O_EXCL | O_TRUNC)) { > > case O_CREAT | O_EXCL: > > case O_CREAT | O_EXCL | O_TRUNC : > > // Ignore O_TRUNC if we get O_CREAT | O_EXCL > > create = CREATE_NEW; break; > > case ...: > > } Yeah I was not a huge fan of these if/else chains. Thanks. - Andrew ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66424/#review200579 ----------------------------------------------------------- On April 3, 2018, 10:47 p.m., Andrew Schwartzmeyer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/66424/ > ----------------------------------------------------------- > > (Updated April 3, 2018, 10:47 p.m.) > > > Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, > and Michael Park. > > > Bugs: MESOS-8673 > https://issues.apache.org/jira/browse/MESOS-8673 > > > Repository: mesos > > > Description > ------- > > Instead of using the CRT implementation of `_wopen()` for the > `os::open()` API, we now use the Windows API `CreateFileW()`, mapping > each of the Linux `open()` flags to their semantic equivalents. This > will make implementing overlapped I/O possible, and is a step toward > removing the use of integer file descriptors on Windows. > > Note that instead of redefining the C flags like `O_RDONLY`, we just > use them directly in our mapping logic, and set the used but > unsupported flags to zero. > > This change uncovered several bugs such as incorrect access flags, and > used-but-not-included headers. > > We currently ignore creation permissions as they will be handled in a > broader project to map permissions to Windows correctly. > > > Diffs > ----- > > 3rdparty/stout/include/stout/net.hpp > d2992c05b221ea90dae1c06d27753932f7411925 > 3rdparty/stout/include/stout/os/windows/fcntl.hpp > bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa > 3rdparty/stout/include/stout/os/windows/mktemp.hpp > 5c775c45c415d9ddd6a80ab814fb55475e9f871e > 3rdparty/stout/include/stout/os/windows/open.hpp PRE-CREATION > 3rdparty/stout/include/stout/windows.hpp > 1bfcdf4a5c097cc6d2293396ce39c8ad2c9ec993 > > > Diff: https://reviews.apache.org/r/66424/diff/1/ > > > Testing > ------- > > > Thanks, > > Andrew Schwartzmeyer > >
