-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use conditional compilation for Lwt_unix + OCaml 4.05 compat (O_KEEPEXEC) #322
Conversation
hmm no CI? Are all the bots sleeping, or is CI skipped if the branch is created directly on this repos? |
lwt.opam
Outdated
@@ -35,6 +35,7 @@ depends: [ | |||
"ocamlfind" {build & >= "1.5.0"} | |||
"ocamlbuild" {build} | |||
"result" | |||
"cppo" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can add the {build}
predicate here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, pushed.
Not sure what just happened with the AppVeyor CI. I don't have time to debug it at the moment. I restarted the builds. If you keep having problems, you're welcome to comment out build rows/disable AppVeyor, and I will look later. |
And
Maybe it was just taking a while to be submitted by GitHub. CI is enabled for branches created directly on the repo. In fact, I'd like to disable double building of PRs from branches on the repo, but neither AppVeyor nor Travis supported this as of two months ago. |
Thank you both for the extra eyeballs :) Indeed CI eventually launched after a while (around an hour an a half or so) -- I was used to Github doing its thing faster. Will sit on this for a few days (4.05 is not released yet) before merging just in case we/somebody find a reason not to. |
@mfp I pushed into this branch a commit to enable testing on Also, I think it will be necessary to add |
4.05 CI: was doing the same in a (now deleted) branch :) Most lwt versions had more conservative constraints (4.02 or 4.03), so there weren't that many in need of a change. ocaml/opam-repository#8578 Surprisingly, 2.4.5 builds on 4.04 as per http://opam.ocamlpro.com/builder/html/report-full.html#lwt |
Looks like we need to wait on Camlp4 for 4.05 to be in OPAM for the CI to work. Fortunately, there is a PR: ocaml/opam-repository#8583. I'll restart the build when that's in. Thanks for the constraints.
2.4.5 builds on 4.04 because that was the last old release before the Lwt PPX:
There were some incompatibilities in the PPX when 4.03 came out, fixed in Lwt 2.5.2. I guess the PR was #227. |
See comment included in the diff for details.
[skip appveyor]
a37cf94
to
361fcaa
Compare
Should be ready for merge now. |
Don't forget to update the c stub, it already happend in the past at this point: #170 The sizes of https://github.com/ocaml/ocaml/blob/dd0d93f0f1b2c9e9c91713ae3aac0accbbf82310/otherlibs/unix/open.c#L41 and Line 1113 in 0f37f8e
must be kept in sync. Otherwise |
On Mon, Mar 06, 2017 at 04:43:44AM -0800, Andreas Hauptmann wrote:
Don't forget to update the c stub, it already happend in the past at this point: #170
The sizes of https://github.com/ocaml/ocaml/blob/dd0d93f0f1b2c9e9c91713ae3aac0accbbf82310/otherlibs/unix/open.c#L41 and https://github.com/ocsigen/lwt/blob/0f37f8e8c970cec9b22588ee9b2034e141bbbb17/src/unix/lwt_unix_unix.c#L1113
must be kept in sync. Otherwise `caml_convert_flag_list` could return garbage, if you pass `O_KEEPEXEC` to it.
Great catch, thanks a lot!
I'm updating the PR.
…--
Mauricio Fernández
|
We're now using ocaml-migrate-parsetree in cstruct, so the bulk build train for 4.05 is now blocked on Lwt again :-) mirage/ocaml-cstruct#127 Would be great to get this built into a release so that the 4.05 betas work. |
This is going into a |
On Wed, Mar 22, 2017 at 10:15:54AM -0700, Anil Madhavapeddy wrote:
We're now using ocaml-migrate-parsetree in cstruct, so the bulk build train for 4.05 is now blocked on Lwt again :-) mirage/ocaml-cstruct#127
Would be great to get this built into a release so that the 4.05 betas work.
Sorry about the delay. I'm planning to revisit the patch this weekend.
…--
Mauricio Fernández
|
The default close-on-exec behavior for Unix.openfile might change in future OCaml releases, refer to ocaml/ocaml#650 This patch ensures Lwt_unix.openfile's default behavior will match Unix.openfile (and also keep consistency w.r.t. it between Win32 and other platforms).
I tried to write some tests for O_CLOEXEC/O_KEEPEXEC but frankly it was a PITA: pre-processor needed to test 4.05's O_KEEPEXEC, platform-dependent code to test Edit added separate issue for |
I think writing a private one-off program for testing, and exercising the various combinations once locally, is fine for now. |
src/unix/lwt_unix_unix.c
Outdated
cloexec = 0; | ||
#endif | ||
|
||
#if !defined(NEED_CLOEXEC_EMULATION) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand it, with this diff, NEED_CLOEXEC_EMULATION
will no longer ever be defined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed. I lost the line that defined NEED_CLOEXEC_EMULATION
if O_CLOEXEC
wasn't defined in the last-second patch cleanup, and missed it since Linux + glibc does have O_CLOEXEC
.
Should be fixed now.
I bit the bullet and tested both |
tests/unix/test_lwt_unix.cppo.ml
Outdated
Lwt_unix.close fd >>= fun () -> | ||
Lwt_unix.waitpid [] n >>= function | ||
| _, Unix.WEXITED 0 -> Lwt.return_true | ||
| _ -> Lwt.return_false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this is failing the automated builds with warning 4, because it does not list the cases for the Unix.process_status
explicitly, and we have lots of warnings enabled, and build with warnings as errors in CI. I think in this case, it's best to just list the two remaining possible cases explicitly, so we fail out in the extremely unlikely event Unix.process_status
changes one day.
Much appreciated! |
Compatibility with OCaml 4.05, broken with the introduction of the
O_KEEPEXEC
constructor inUnix.open_flag
, see #321.Tested on 4.02.3 and 4.05+beta2.
I'm getting these apparently benign warnings, which I have not been able to prevent (I didn't find the proper way to use InterfacePatterns/ImplementationPatterns apparently):