libera/#sbcl - IRC Chatlog
Search
13:40:23
jackdaniel
I've noticed that sbcl finalizers take no arguments - on some implementations they accept as the argument the finalized object (so it could be i.e reintroduced into the environment) -- is there a technical reason why is that or it is just how it is for historical reasons?
13:43:20
stassats
you could touch its husk, but anything else it touches and enlivened only by it will be dead
13:43:46
stassats
so to get a real object you would need some different GC mode, where lots of things are temporarily not dead
13:44:38
jackdaniel
right, in ecl objects are passed to the finalizer before they are collected and left be until the next cycle
13:45:08
jackdaniel
(so the finalizer may decide to reintroduce the object); so in other words that would be technically unsuitable for sbcl
13:46:13
stassats
but how would it know that the only reason the object is alive is because it's referenced by a finalizer
13:48:44
jackdaniel
my understanding is that when it deems some object dead, then it passes it to the finalizer as an argument. but this is quite troublesome, because if objects referenced from that object also have finalizers, then they are postponed further away
13:54:30
stassats
sbcl uses weak pointers for finalization, and then just looks a the weak pointers that became dead
13:55:53
stassats
so for the finalizers it could do, look at the finalized objects, enliven them but mark them as being dead once, then the finalizer runs and removes them from the finalizer store
13:56:28
jackdaniel
interesting! indeed, for that current api makes more sense. thanks again for the explanation
13:57:12
stassats
but i guess what if stays alive but is backed by something that is already finalized, like foreign memory
14:02:45
jackdaniel
I don't understand the remark about backing by a foreign memory that is already finalized
14:03:24
stassats
the finalizer is ready to run on it, and it's just a free() on some foreign memory, but then it stays alive but no longer usable
14:03:27
jackdaniel
if object references that memory, then it won't be garbage collected (because it is reachable from that object) - that's what I've meant when I've mentioned "postponing further away"
14:05:42
jackdaniel
and if it is i.e something like a file handler that is closed in the finalizer, then indeed the object could get corrupted if reintroduced into the environment - but that would be the programmer fault (and wouldn't differ much from closing it normally in a function that is not a finalizer)
14:09:04
jackdaniel
what I mean is "it would be not much different from closing the stream by accident in any other function" -- if I understand correctly that seems to be orthogonal to finalizers
14:09:24
jackdaniel
just like the programmer fault would be capturing the object by the finalizer (as mentioned in sbcl manual)
14:10:59
stassats
if there's no way to free an object other than when it becomes dead, then there can't be a normal situation where it becomes accidentally dead
14:11:11
jackdaniel
yes, and if you do that when you open files then you'll end up with no descriptors in no time
14:12:25
jackdaniel
I agree, it is quite descriptive. either way I know everything I've tried to inquiry- so I'm satisfied, thanks again
14:13:40
stassats
If DONT-SAVE is true, the finalizer will be cancelled when SAVE-LISP-AND-DIE is called: this is useful for finalizers deallocating system memory, which might otherwise be called with addresses from the old image.
14:23:11
Shinmera
So, a lot of publishers are asking me about eventual publishing of Kandria on consoles, especially Switch. I know Switch has a weird microkernel architecture that SBCL would need porting to (along with other libraries I'm sure). Just out of curiosity, would anyone here be available for hiring of such a port, and with an extremely rough estimate, how much work would it entail? It runs on ARM64, so at
14:24:47
Shinmera
I imagine they'd also have a C library of some kind in their official dev kit, but that's closed source and not public, so.
14:25:21
Shinmera
There's a couple of homebrew libraries floating around as well, though I have no clue on their viability.