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

flambda changes to finalisability should be documented #7356

Closed
vicuna opened this issue Sep 14, 2016 · 2 comments
Closed

flambda changes to finalisability should be documented #7356

vicuna opened this issue Sep 14, 2016 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Sep 14, 2016

Original bug ID: 7356
Reporter: @yallop
Status: acknowledged (set by @damiendoligez on 2016-09-28T11:50:22Z)
Resolution: open
Priority: normal
Severity: feature
Target version: 4.05.0 +dev/beta1/beta2/beta3/rc1
Category: documentation
Monitored by: braibant @dbuenzli

Bug description

flambda's optimisations can change whether a value is finalisable. For example, the following program executes without error when compiled with 4.04.0+beta1, but exits with an exception (Invalid_argument("Gc.finalise")) when compiled with 4.04.0+beta1+flambda

   let f x = Gc.finalise ignore (fun () -> x; ())
   let () = f ()

A section on finalisability would fit well in the flambda chapter alongside the sections about inhibition of optimisation (20.14) and about unsafe operations (20.15).

http://caml.inria.fr/pub/docs/manual-ocaml/flambda.html#inhibition
http://caml.inria.fr/pub/docs/manual-ocaml/flambda.html#sec507
@vicuna
Copy link
Author

vicuna commented Dec 6, 2016

Comment author: bobot

It seems that we should have a way to create a value that is finalisable. Perhaps val make_finalizable: 'a -> 'a that could or not copy the value.

@vicuna vicuna added this to the 4.05.0 milestone Mar 14, 2019
@nojb nojb added the flambda label Mar 16, 2019
@github-actions
Copy link

github-actions bot commented May 9, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

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

No branches or pull requests

2 participants