Caml_alloc: Document new behaviour and upgrade path (check_urgent_gc)#8941
Caml_alloc: Document new behaviour and upgrade path (check_urgent_gc)#8941gasche merged 1 commit intoocaml:trunkfrom
Conversation
| execution. These asychronous callbacks can execute arbitrary OCaml | ||
| code, including raising asynchronous exceptions. | ||
|
|
||
| The function \verb"caml_check_urgent_gc" from "memory.h" checks for |
There was a problem hiding this comment.
Thanks for the docs @gadmm. Isn't that a very bad name for what it's doing ? I mean if I'm checking something I rather expect an existence test, not side effects. Maybe caml_exec_urgent_gc would be a better name ?
There was a problem hiding this comment.
This name cannot change for backwards compat, but I'm open to suggestions for the name of a new function that takes void as argument instead. caml_async_callbacks, caml_safe_point...
There was a problem hiding this comment.
Ah sorry didn't get this was already in the wild.
|
|
9e68476 to
aa13b8c
Compare
gasche
left a comment
There was a problem hiding this comment.
Merging on behalf of @jhjourdan's approval. Thanks @dbuenzli and @jhjourdan for your help, and thanks @gadmm for the documentation.
This is a follow-up to #8691 (comment). I find it a good idea to document the new behaviour of allocation functions and give an upgrade path for users of the C FFI in case they could be affected, e.g. if they have long-running C code. Currently this does not change any code.
However, I find three issues with the current interface and I may improve it according to feedback.
check_urgent_gcis currently hard to follow in resource-conscious C code, because when an asynchronous exception must be raised, it automatically jumps back to the OCaml caller and prevents cleanup. (This is an issue the Coq VM is facing for instance.) A solution would be to have a variant ofcheck_urgent_gc_exnthat returns the exception, and document that it has to be reraised withraise_in_async_callback. (It looks like some amount of work, but I see how it could help in situations like the Coq VM.). The same should be done for{enter,leave}_blocking_section.check_urgent_gcis not called when an allocating C function returns to OCaml, unlike I had documented at first. This can have unexpected consequences given that OCaml is currently poor in emitted safe points (cf. the problem of uninterruptible loops). There are possibilities that this causes bugs in current programs. I read that a solution is to changecaml_c_call, but this could also have a much simpler fix after the better safe points patch.Note: it's good to consider this for 4.10