WIP run finalizers on own thread

[miguelraz]

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

[maleadt]

Does that imply finalizers might be run in a different task than the one in which an object was created?

[yuyichao]

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.

[miguelraz]

I believe so - but I'm definitely not the expert here.
The plan according (yet to be lost to the slack hole in #multithreading) is the following:

Jeff Bezanson 
In threading.c:jl_start_threads, we need to start one more thread with a custom thread function that waits on a condition and then runs a list of finalizers when signaled.
Jeff Bezanson  
Where we currently run finalizers at the end of gc_collect, instead signal the condition.
Jeff Bezanson 
(If julia is started with >1 thread)
...
miguel raz guzmán  
Should it mirror partr.c:jl_threadfun or be spawned right after the loop thread in threading.c:jl_start_threads
Jeff Bezanson
It will be similar to jl_threadfun, since it needs most of the same init calls. I'd put it in gc.c since it's part of the GC.

[JeffBezanson]

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.

[JeffBezanson]

This should use uv_cond_signal.

[JeffBezanson]

Need a declaration of jl_gc_threadfun_finalizer in this file.

[fingolfin]

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?

[vchuravy]

We now have a thread that uses concurrent sweeping, so we could use that thread for finalizers as well.
We have an open issue so I don't think this PR needs to stay open.