On Sat, Oct 12, 2002 at 06:03:07PM +0100, Alastair Reid wrote:
>
> > For the record, I am strongly in favor of Haskell finalizers, if a
> > Mutable State extension were to be written, then it will have to
> > address the issue with one of the solutions mentioned in this
> > thread,
>
> We already have a perfectly good Mutable State extension. We know
> exactly what it looks like. It's already implemented by all compilers
> that support the FFI.
>
> There's really no question of putting off solving FFI-induced problems
> until such an extension exists. The extension exists now, the problem
> would have to be solved now.
True, but I just meant that the exact details of the Mutable State
extension need not be specified in the FFI, if we can convince ourselves
that a solution is possible, then we can move on with the FFI
discussion.
Personally, I think that a Mutable State specification that mentioned
something about 'potentially concurrent' computations is probably useful
as they arrise in several places, not just finalizers. if I thought this
problem was an isolated example which only pertained to finalizers then
just C finalizers might be a solution, but we are going to have to
tackle this eventually, and probably soon. 'potentially concurrent'
computations come up whenever you want to write portable library code
which makes use of state, if there is a chance it will ever be used in
an implementation with concurrency. They would also be useful if an
implementation wanted to implement asyncronous signal handling without
invoking concurrency.
My solution to this problem has been part of my autoconf script which
detects the presence of MVars and when they do not exist, defines
newMVar, modifyMVar, swapMVar, readMVar, and writeMVar in terms of
IORef. that way I know my libraries will work everywhere independent of
the presence of concurrency. this solution seems to work rather well as
you cannot deadlock the system with just those primitives.
>
> > The ability to tie the liveliness of ForeignPtrs together is quite
> > important for many applications.
>
> Can you give an example? (Maybe there's a paper that mentions it,
> I'll happily go read that.)
at least two papers mention it that i know of off the top of my head,
the paper which describes the implementation of Weak, ForeignPtr etc.
It claims one of the motivations for weak pointers is to inform the
garbage collector of dependencies which may not exist on the haskell
side of things. they use interfacing with C code as an example.
the other paper is the FFI spec itself! the section for
touchForeignPtr says that it should be used to express dependencies
between foreignptrs by calling it in the finalizers of other
foreignptrs. oddly enough, that means the spec is currently quite
internally inconsistant since we cannot make such calls. (!!)
I personally have used it in both my ncurses and openssl interfaces, in
openssl you have opaque structures which contain links to other opaque
structures. in haskell they are represented by ForeignPtr's with
finalizers that destroy them, however a common thing to do is create an
RSA object and place it within some other object. once the haskell
reference to the RSA object disapears suddenly it is freed out from
under the other object and all heck breaks loose! the solution is to
create a weak link from the encryption object to the RSA object making
sure it lasts as long as the encryption object. right now the only ways
to do that are using 'mkWeak' to create the link, or touchForeginPtr rsa
in the encryption object finalizer to make sure it still exists (as it
recommends as the portable way in the FFI spec.)
John
--
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED]
---------------------------------------------------------------------------
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
