I guess the Hugs documentation should say that using unsafePerformIO
to call C which calls Haskell should be avoided.
Yes it should, if such behaviour can lead to strange crashes! Better
still would be to work out exactly what constraints are required on the
use of eval() from primitive
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
| I claim that the major thing that finalizers do is manipulate shared
| state.
That is certainly true. If they were pure, you'd never know they'd run!
| To get any benefit from writing finalizers in Haskell, I have to have
| MVars which protect against finalizers.
Nearly right, but not
| type MVar# s elt-- primitive
|
| newMVar#:: State# s - (# State# s, MVar# s elt #)
| takeMVar# :: SynchVar# s elt - State# s - (# State# s, elt #)
| putMVar#:: SynchVar# s elt - State# s - State# s
Bad idea to look at the primops. The important things are
Simon Peyton-Jones [EMAIL PROTECTED] writes:
| takeMVar# :: SynchVar# s elt - State# s - (# State# s, elt #)
| putMVar#:: SynchVar# s elt - State# s - State# s
Bad idea to look at the primops.
(a) It was the first mention of MVars that I found in the docs.
(b) I only really
| (a) It was the first mention of MVars that I found in the docs.
| (b) I only really mentioned it because the type sigs are wrong.
Hmm. That's not very clever.
| Doesn't it block if another thread manages to sneak a putMVar into
| the middle? Maybe I should read your Awkward Squad paper to
| To get any benefit from writing finalizers in Haskell, I have to have
| MVars which protect against finalizers.
Nearly right, but not quite. You might write a Haskell finalizer
that did lots of useful things (e.g. consulted a large pure data
structure) before doing its state-mutation by
I don't think = is frequent enough. Pure code that manipulates
big C objects (remember that image processing example of mine?) can
generate a lot of garbage C objects without once going into the IO
monad.
Also, thanks to unsafePerformIO, = can be invoked during execution
of a primitive
Yes, that's right. It is often the case that there *is* no shared
state so a Haskell finalizer is fine. But if there is, then there
has to be some mechanism for atomic operations. C is one such
mechanism.
I claim that the major thing that finalizers do is manipulate shared
state. Their
On Wed, Oct 09, 2002 at 02:02:35PM +0100, Alastair Reid wrote:
So are you saying that if a GC were to occur in the middle of a
C-implemented Hugs primitive, it could be bad news?
It's possible. It's something we never had to consider when writing
the Hugs primitives so we never took
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
Simon Peyton-Jones [EMAIL PROTECTED] writes:
You didn't respond to my proposal, perhaps because it didn't seem like
one (I've changed a few words).
I think I agree with your proposal as far as nhc98 is concerned.
Regards,
Malcolm
___
FFI
On Wed, Oct 09, 2002 at 04:09:07PM +0100, Alastair Reid wrote:
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
Some comments on the question of finalisers.
Firstly, a retraction. In nhc98, it *is* possible to implement Haskell
finalisers, by creating a `pending' list of finalisers during the GC,
and then running them immediately the GC finishes. I see several
messages in the archive where I claimed the
In fairness I should state that here at Bremen we do not currently need Haskell
finalizers.
I was thinking of another application altogether, but I don't particularly want to go
into
details of that. There are however particular reasons (such as galloping concurrency)
why
I think Alastair's
15 matches
Mail list logo
