WIP run finalizers on own thread#39529
Conversation
|
Does that imply finalizers might be run in a different task than the one in which an object was created? |
That has always been the case. |
|
I believe so - but I'm definitely not the expert here. |
| free(targ); | ||
|
|
||
| (void)jl_gc_unsafe_enter(ptls); | ||
| jl_finish_task(jl_current_task); // noreturn |
There was a problem hiding this comment.
Calling this will cause the thread to run the scheduler, and start trying to pull general tasks from the queue to run. We don't want to do that; instead it should run a loop that waits on a condition and then calls run_finalizers.
|
|
||
| // signal conditions for finalizer thread | ||
| if (!ptls->finalizers_inhibited && ptls->locks.len == 0) | ||
| jl_gc_thread_finalizer_wait_cond(ptls); |
There was a problem hiding this comment.
This should use uv_cond_signal.
| uv_thread_create(&uvtid, jl_threadfun, t); | ||
| } | ||
| else { | ||
| uv_thread_create(&uvtid, jl_gc_threadfun_finalizer, t); |
There was a problem hiding this comment.
Need a declaration of jl_gc_threadfun_finalizer in this file.
|
WIP PR last worked on in mid 2021. Has conflicts. In the meantime we got support for multiple GC threads -- about which I know little to nothing, but I wonder if there is overlap/conflict? Anyway, it was also referenced elsewhere in December 2023, so maybe there is merit in keeping this around just in case someone decides to pick up the work again? |
|
We now have a thread that uses concurrent sweeping, so we could use that thread for finalizers as well. |
This is a horrible, no good, very bad first draft.
It likely has a gajillion errors in logic, spelling, judgement and competence.
... but a first draft was made to tackle #35689.
cc @JeffBezanson