"Simon Marlow" <[EMAIL PROTECTED]> wrote,
> I've added a finalizer rationale document to the repository, under
> haskell-report/ffi (i.e. the same place as the FFI spec). If you have
> CVS commit privs, please feel free to modify it, or otherwise suggest
> changes on this list.
Thanks a lot for
On Mon, Oct 14, 2002 at 10:38:55PM +0100, Alastair Reid wrote:
> [...]
> There's a few details to take care of (e.g., avoiding calling cons in
> scheduleFinalizer) but they're all manageable.
Indeed: a ForeignPtr has a list of finalizers, so you can use appendOnto().
In fact there is already a li
I was thinking that blockFinalizers would not be exported, but rather
used to implement whatever Mutable State standard with 'potential
concurrency' is proposed. PVars, subset of MVars, atomic IORefs or
whatnot, and in the implemententaion of the standard library to make
sure it is finalizer-safe.
>> blockFinalizers :: IO a -> IO a
> Indeed, I very nearly implemented such a thing as part of the patch
> I sent out. However, it didn't look trivial enough to implement so
> I backed off. The "blocked" state needs to be saved & restored at
> various points: when starting a finalizer, when in
On Mon, Oct 14, 2002 at 11:07:27AM +0100, Malcolm Wallace wrote:
> > and if we are adding things to the FFI spec, how about the empty data
> > declaration? it is painfully simple to implement and would make FFI code
> > a lot cleaner as it tends to depend heavily on placeholder types..
>
> Hugs a
I dont have cvs write access but you should mention something about
expressing gc dependencies between ForeignPtr's. the only two ways to do
this in the current haskell systems are
* weak pointers
* touchForeignPtr from the finalizer of another ForeignPtr
if the second one is not allowed by restr
Oops, I sent the attached document to the wrong mailing list. This is
a comment on SimonM's finalizer document. I decided to comment rather
than edit since my comments require more than tweaking the odd word
here and there.
--
Alastair
Things you mights add are:
eg(1) in composite finalizer
>> and if we are adding things to the FFI spec, how about the empty
>> data declaration? it is painfully simple to implement and would
>> make FFI code a lot cleaner as it tends to depend heavily on
>> placeholder types..
> Hugs and ghc already have it (AFAIK). I recently added it to nhc98.
> D
> Thanks to everyone who has contributed to this discussion so
> far. Since
> there are a lot of subtle points to be considered at once, I
> thought I'd
> try to write a summary of the issues raised so far.
>
> I'll put something in the repository so we can all hack on it.
> Hopefully I'll hav
> Thanks to everyone who has contributed to this discussion so
> far. Since
> there are a lot of subtle points to be considered at once, I
> thought I'd
> try to write a summary of the issues raised so far.
>
> I'll put something in the repository so we can all hack on it.
> Hopefully I'll ha
> 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 ope
Thanks to everyone who has contributed to this discussion so far. Since
there are a lot of subtle points to be considered at once, I thought I'd
try to write a summary of the issues raised so far.
I'll put something in the repository so we can all hack on it.
Hopefully I'll have something ready
> > However even if Haskell finalizers + MVars are impossible in NHC, I
> > don't think Haskell finalizers + mutable state have to be. For
> > example another mutable variable we could have would be a PVar which
> > is always full and has functions [snip]
>
> > updatePVar (PVar ioRef) updateFn
John Meacham <[EMAIL PROTECTED]> writes:
> Just musing about the need some people have for ForeignPtrs to be
> deallocated deterministly, perhaps something like C#'s 'using' construct
> is in order which would enforce a stacklike allocation policy for
> ForeignPtrs...
If you need deterministic
14 matches
Mail list logo
