Fix Thread.sigmaks, by checking whether a signal is masked before handling it.
We use [sigprocmask] (if available) to check whether a signal is
blocked when the systhread library is not loaded. As soon as the
[Thread] module gets loaded, we use [pthread_sigmask] instead, and
redirect all the calls to [sigprocmask] to [pthread_sigmask]. Indeed,
the latter has unspecified behavior in a multi-threaded context
anyway. In practice, this should not change the semantics of
[Unix.sigprocmask] on Linux, since on this platform, [pthread_sigmask]
is actually an alias for [sigprocmask]. On MacOSX, the semantics will
change, since [sigprocmask] changes the masks of the whole process on
this platform.
Also, include [caml_pending_signals] in signals returned by
[Unix.sigpending]. Indeed, some signals might have been handled in the
POSIX sense by the C handler in the OCaml runtime, but not been
handled in the OCaml sense (for example, because they are blocked).
This commit un-reverts 1c82c481a, which has been reverted in
79eb572e4. The issues of the original commit are corrected in this commit.
Because otherwise it is not possible to initialize it with a constant
C string when compiling with a C++ compiler without getting a warning:
ISO C++11 does not allow conversion from string literal to 'char *'
[-Wwritable-strings]
No tests seams to be more annoyed by this change but of course it is
always possible that some code in the wild relies on this field to be
non-const. This is indeed an API change, although a trivial one.
(dune seems to choke on some 4.08 features that were used in the Env
codebase already. It's not a bad idea to ensure that the compiler
codebase works well with 4.07.)
This commit removes an unused file introduced by commit
6526a0c3d9
It is important to remove this file because it does not quite work:
it assumes ocamlc.byte has already been installed and thus uses an
installed compiler rather than the one to test so that would be a
misleading source of inspiration for test writers.
The hope is that a tailor-made algebraic datatype is more readable /
less confusing than using ('a option) directly -- one may confuse
getting None when looking in a table with the Not_found case.
(Suggested by Jérémie Dimino)