Open Grinshpon opened 3 years ago
Thanks for the report!
This is intentional and documented. The best way to work around it is to construct your Runtime
at the very start of your main
function, run
it immediately, and keep running it until the very end of your main
function, as documented here.
Leaving this issue open, because the rule should be documented more prominently, particularly in the rustdoc pages for Root
, Gc
and Val
. We should probably add a more explicit warning to the-glsp-crate.md
, too. This rule used to be documented alongside the GSend
marker trait, but that trait was removed in version 0.2, so the documentation is currently a little sparse.
Ah, I see, thank you!
Just curious, is there a significant performance difference in calling run
once and keeping it active, versus calling it once or more each frame?
run
is basically free! It just changes the value of a thread-local Option<Rc<_>>
, and then changes it back after running the closure.
In a project, I have a state struct that contains a glsp runtime and a struct that holds callbacks:
At the very end of the program, when the state is dropped, it panics with the error:
a Root or Gc has outlived its originating Runtime - aborting process
I then tried manually dropping the callbacks before the end of the program, and it seems the panic occurs there, so it looks like I can't drop
Root
s unless I'm in a runtime environment. Is this intentional?