What hasn't been required is for the various data structures to be in a consistent state at that point, and Haskell finalizers might trip over those if run after GC. SimonM's patch ran them at a different point, though.
It calls them in eval doesn't it? eval is called by nearly every primitive in Hugs. Most calls are benign since the calls are at the start of the primop before any data structures have been fiddled with.
It's even possible that none have any problems. All I'm saying that we will have to look over the code before we know if there is a problem (while others are claiming that there couldn't possibly be a problem).
Actually, I was claiming that if there's a problem there, then it's one you already have. The reasoning I used is just that eval() can call a foreign function, which can re-enter Hugs. My patch added no new code paths (as I said before). Perhaps there *are* problems with existing primitives which call eval(), but you need to check those anyway. Cheers, Simon
SimonM:
Actually, I was claiming that if there's a problem there, then it's one you already have. The reasoning I used is just that eval() can call a foreign function, which can re-enter Hugs. My patch added no new code paths (as I said before).
I guess the Hugs documentation should say that using unsafePerformIO to call C which calls Haskell should be avoided. Off the top of my head, I'd say that most legitimate (i.e., safe) uses of unsafePerformIO don't have problems. I think Haskell finalizers are different: virtually every finalizer which manipulates Haskell state will have race conditions. -- Alastair
participants (2)
-
Alastair Reid -
Simon Marlow