| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Systhreads can use this hook to initialize the systhreads machinery before any
OCaml code runs on the corresponding domain.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, Thread.exit tried to behave exactly like pthread_exit():
it stops the current thread immediately, but doesn't stop the whole
program as long as other threads keep running.
As discussed in #9071, this behavior is a problem for resource management
("finally" functions are not called).
As discussed during the Multicore merge review and reported in #10927,
this behavior is a problem in the presence of multiple domains.
As first proposed in #9100, this PR reimplements Thread.exit by
simply raising a dedicated Thread.Exit exception. This is good for
resource management ("finally" functions are properly called)
and simplifies the implementation tremendously.
It does introduce incompatibilities with OCaml 4. In particular, if
`Thread.exit` is called from the main program or from a domain but not
from a thread started by `Thread.create`, the exception `Thread.Exit`
is not automatically caught and will abort the program / the domain,
unless explicitly handled by the program.
Following the discussion at #10935, `Thread.exit` is marked as deprecated
with the suggestion to use `raise Thread.Exit` instead, and we'll try
to introduce `Thread.Exit` in 4.14 (without changing `Thread.exit` behavior)
so that it is possible to write code that works both in 4.14 and in 5.00.
Fixes: #9071
Closes: #9100
Fixes: #10927
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the same thread the allocation takes place.
This is done by using a local entry array for each thread, containing
tracked blocks whose allocation callback has not yet been called.
This allows some simplification in the code running callbacks for
young allocations. Indeed, since the entry array is local to one
thread, we know for sure that it cannot be modified during a callback,
and therefore we no longer need to remember the indices of the
corresponding new entries.
|
| |
|
|
| |
ocamlopt.byte (#9677)
|
| | |
|
| |
|
|
|
|
|
|
| |
that file. (#9063)
The original test had a race condition between finalization and thread preemption.
That was probably the cause for the wrong backtrace observed here:
https://github.com/ocaml/ocaml/pull/8641#issuecomment-544231899
|
| |
|
|
|
|
|
|
| |
The previous mechanism worked for C calls that raise an exception, but not for C calls that call back into OCaml code which raises an exception.
This commit addresses the issue by saving the PC in the interpreter stack before a C call, so that the backtrace mechanism always sees it.
However, if an external is declared in the .ml file and exposed in the .mli file as a val, then ocamlc generates a wrapper that adds a spurious entry in the stack frame. In this PR, this change in behavior results in the re-declaration of Printexc.get_callstack as an external instead of a val, so that the spurious stack frame does not appear in call stacks obtained from Printexc.get_callstack.
|
| | |
|
|
|
The `top_of_stack` field of the `th` descriptor for the new thread was initialized too late, causing `caml_top_of_stack` to be NULL when the thread starts running. The fix is to initialize `th->top_of_stack` earlier.
|
