Skip to content
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

Merged
merged 10 commits into from
Apr 7, 2017

Conversation

mfp
Copy link
Collaborator

@mfp mfp commented Feb 28, 2017

Compatibility with OCaml 4.05, broken with the introduction of the O_KEEPEXEC constructor in Unix.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):

W: Cannot find source file matching module 'Lwt_unix' in library lwt-unix.
W: Use InterfacePatterns or ImplementationPatterns to define this file with feature "source_patterns".
W: No exported module defined for library lwt-simple-top
W: No exported module defined for library lwt-syntax-options
W: Cannot find source file matching module 'Lwt_unix' in library lwt-unix.
W: Use InterfacePatterns or ImplementationPatterns to define this file with feature "source_patterns".
W: No exported module defined for library lwt-simple-top
W: No exported module defined for library lwt-syntax-options
W: Cannot find source file matching module 'Lwt_unix' in library lwt-unix.
W: Use InterfacePatterns or ImplementationPatterns to define this file with feature "source_patterns".
W: Cannot find source file matching module 'Lwt_unix' in library lwt-unix.
W: Use InterfacePatterns or ImplementationPatterns to define this file with feature "source_patterns".

@mfp
Copy link
Collaborator Author

mfp commented Feb 28, 2017

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"
Copy link
Contributor

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, pushed.

@aantron
Copy link
Collaborator

aantron commented Feb 28, 2017

XOCamlbuildPluginTags was broken in OASIS 0.4.7 and fixed in 0.4.8 (ocaml/oasis#84, changelog), so should also change the oasis constraint in opam to >= 0.4.8. Looks good modulo this and @vasilisp's comment.

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.

@aantron
Copy link
Collaborator

aantron commented Feb 28, 2017

And

hmm no CI? Are all the bots sleeping, or is CI skipped if the branch is created directly on this repos?

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.

@mfp
Copy link
Collaborator Author

mfp commented Feb 28, 2017

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.

@aantron
Copy link
Collaborator

aantron commented Feb 28, 2017

@mfp I pushed into this branch a commit to enable testing on 4.05+beta2 in Travis. Hopefully, that will go well.

Also, I think it will be necessary to add < 4.05 compiler constraints to all the existing lwt packages in OPAM. If you don't want to do this tedious work, I will do it some time before the 3.0.0 release :)

@mfp
Copy link
Collaborator Author

mfp commented Feb 28, 2017

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

@aantron
Copy link
Collaborator

aantron commented Mar 2, 2017

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.

Surprisingly, 2.4.5 builds on 4.04

2.4.5 builds on 4.04 because that was the last old release before the Lwt PPX:

$ git tag --contains `git log --reverse --format='%H' -- ppx | head -n 1`                                                                      141
2.4.6
2.4.7
2.4.8
2.5.0
2.5.1
2.5.2
2.6.0
2.7.0

There were some incompatibilities in the PPX when 4.03 came out, fixed in Lwt 2.5.2. I guess the PR was #227.

aantron added 2 commits March 2, 2017 19:06
See comment included in the diff for details.
@aantron aantron force-pushed the lwt_unix+4.05-compat branch from a37cf94 to 361fcaa Compare March 3, 2017 01:07
@aantron
Copy link
Collaborator

aantron commented Mar 3, 2017

Should be ready for merge now.

@fdopen
Copy link
Contributor

fdopen commented Mar 6, 2017

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

static int open_flag_table[] = {

must be kept in sync. Otherwise caml_convert_flag_list could return garbage, if you pass O_KEEPEXEC to it.

@mfp
Copy link
Collaborator Author

mfp commented Mar 6, 2017 via email

@avsm
Copy link
Collaborator

avsm commented Mar 22, 2017

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.

@aantron
Copy link
Collaborator

aantron commented Mar 22, 2017

This is going into a 2.x.x release within the next two weeks or so, to be released concurrently with 3.0.0 (where 3.0.0 will contain only the planned breaking changes).

@mfp
Copy link
Collaborator Author

mfp commented Mar 22, 2017 via email

mfp added 2 commits March 25, 2017 23:46
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).
@mfp
Copy link
Collaborator Author

mfp commented Mar 26, 2017

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 Lwt_unix.fork + exec on Unix-like and CreateProcess on win32 separately, etc.

Edit added separate issue for ?cloexec #327

@aantron
Copy link
Collaborator

aantron commented Mar 26, 2017

I think writing a private one-off program for testing, and exercising the various combinations once locally, is fine for now.

cloexec = 0;
#endif

#if !defined(NEED_CLOEXEC_EMULATION)
Copy link
Collaborator

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.

Copy link
Collaborator Author

@mfp mfp Apr 3, 2017

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.

@mfp
Copy link
Collaborator Author

mfp commented Apr 3, 2017

I bit the bullet and tested both O_CLOEXEC and O_KEEPEXEC (when available) on non-Windows.
On win32, Lwt_unix.openfile uses Unix.openfile, so there's not that much to gain in going out of our way to test it, anyway.

Lwt_unix.close fd >>= fun () ->
Lwt_unix.waitpid [] n >>= function
| _, Unix.WEXITED 0 -> Lwt.return_true
| _ -> Lwt.return_false
Copy link
Collaborator

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.

@mfp mfp merged commit 6ec1298 into master Apr 7, 2017
@aantron
Copy link
Collaborator

aantron commented Apr 7, 2017

Much appreciated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants