June 2002 - FFI - Haskell.org

freeHaskellFunPtr
by Sven Panne 17 Jun '02

17 Jun '02

Just for clarification: Is it OK to call freeHaskellFunPtr in the Haskell function pointed to itself, i.e. a kind of "self destruction"? Example: foreign import ccall "wrapper" makeCB :: IO () -> IO (FunPtr (IO ())) ... funPtr <- mfix (\self -> makeCB (do freeHaskellFunPtr self; ...)) <register funPtr somewhere in C land> ... The FFI spec doesn't say anything about this, but it would be very handy if this was allowed, e.g. for one-shot callbacks. After a short look into GHC's and Hugs' RTS I think it is OK for both systems: The thunk/adjustor has always a jump at its end, so free-ing the machine code at the jump destination does no harm. Cheers, S.

2 1

RE: Library archives
by Simon Peyton-Jones 17 Jun '02

17 Jun '02

| The package system provided by GHC and NHC provides an | alternate place where libraries could be specified. Can | someone familiar with packages and with Hugs comment on | whether they'd be able to replace the ffi's library spec and | would make sense for typical Hugs usage. And would that meet | SimonPJ's need too? I honestly don't know, but I don't think it's worth bending the design to accommodate something we aren't actively doing and don't fully understand (ie. a .NET ffi). However, I *believe* that the square bracket part is like the module name in a Haskell qualified name... it says where the name comes from. It makes sense to be able to specify that on a call-by-call basis. Two different libraries might have a procedure with the same name, and you might want to import both into the same FFI interface. Simon

2 1

Library archives
by Alastair Reid 17 Jun '02

17 Jun '02

The current spec contains no examples of how you would specify a library archive. Which of the following are legal: foreign import ccall "[Storable_cbits.o]" readCharOffPtr :: ... foreign import ccall "[libc.so]" malloc :: ... foreign import ccall "[libc.a]" malloc :: ... foreign import ccall "[-lc]" malloc :: ... foreign import ccall "[-L/usr/lib -lc]" malloc :: ... I'm assuming that any relative filenames should be interpreted as being relative to the directory containing the .hs file. My current interpretation is that anything legal on a link line is ok (so all the above are kosher) but it may be sensible to limit it to just the first 3 forms. I'd like the spec to say what's legal and give at least one example. -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

2 2

exporting functions which raise exceptions
by Alastair Reid 14 Jun '02

14 Jun '02

Suppose I foreign export (or wrap) a Haskell function and that function raises an exception, calls exit or raises an error. How should this be reflected on the C side? In a batch-mode system (ghc, runhugs, nhc), we need to call a no_return function like exit but should it always be exit or should there be a way for an application to register an alternative function? (e.g., If my Basic interpreter makes a foreign function call into Haskell, I'd like an error in Haskell to bring me back to the Basic REPL not to quit my program). In an interactive system (ghci, Hugs), the right thing to do seems to be to return to the interpreters REPL. -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

2 6

RE: deRefStablePtr exception?
by Simon Marlow 14 Jun '02

14 Jun '02

> Aha! I was reading the last sentence of the freeStablePtr description > as though it applied to freeStablePtr when in fact it means that > castStablePtrToPtr is guaranteed not to diverge. Well that's a lot > easier to implement. > > btw What am I to make of the parenthetical remark > > (in particular it may be Ptr.nullPtr) > > Should I read that as a recommendation to implementors that when > casting a stableptr which has already been freed then they should > return nullPtr? If so, is this required or just hinted/recommended? I'm not sure where this came from, perhaps Manuel can elucidate. GHC doesn't do this; it just casts the stable pointer value to a Ptr. > > Either 'ErrorCall "Foreign.StablePtr.deRefStablePtr: invalid stable > > pointer"', or a new exception. I don't mind which. > > I'll pick one and add my choice to the spec then. The spec doesn't say anything about exceptions, and it isn't dependent on the implementation also supporting exceptions. So all the spec should say is that deRefStablePtr on a stable pointer which was not generated by newStablePtr, or has already been freed, has undefined behaviour. Cheers, Simon

3 2

Say�n ffi ,
by abdyesilkart.com 14 Jun '02

14 Jun '02

1 0

RE: exporting functions which raise exceptions
by Simon Marlow 13 Jun '02

13 Jun '02

> > When this issue was discussed earlier, I think, SimonM pointed out > > that (especially in the context of concurrency) it is hard to define > > what exactly is supposed to happen with such exceptions. > > I'm not sure I see the difficulty - but I'll go ahead and make up my > own solution (which will probably be much like what GreenCard does...) You probably want the caller to handle the exception, and the caller is probably a C function. So the right way to do it is to catch the exception in Haskell and return some kind of error value to the caller; this is best done by the programmer, since there are plenty of choices for the mechanism used to pass the error value back. The default behaviour of terminating the program (and reporting the exception, of course) is the safest thing to do in the absence of any alternative handling. Cheers, Simon

1 0

RE: deRefStablePtr exception?
by Simon Marlow 13 Jun '02

13 Jun '02

> SimonM: > > That's a good point, I don't think it has any error checking at all. > > Of course the only way to get an invalid stable pointer is by > > calling freeStablePointer on a valid one, or by using the FFI. > > From an imported C function: > > return (HsStablePtr)0 > > From Haskell code: > > castPtrToStablePtr Ptr.nullPtr > > My reading of the description of freeStablePtr is that it is perfectly > legal to pass around a (void*)0 as an HsStablePtr and to hand that to > freeStablePtr and castStablePtrToPtr and expect something meaningful > to happen. The description of freeStablePtr says that the behaviour is undefined when passed an already-freed stable pointer, so I assume it is also undefined if passed a stable pointer that was never obtained from newStablePtr in the first place (perhaps the spec should say this explicitly). But you seem to be saying that freeStablePtr (castPtrToStablePtr Ptr.nullPtr) is meaningful... which part of the spec implies that? > (My personal leanings with anything resembling a C pointer have always > been to use some variant of > > Maybe Addr > Maybe (Ptr a) > Maybe (FunPtr a) > Maybe (StablePtr a) > > if the pointer can possibly be null. It turns out that many functions > assume their argument cannot be null or guarantee that their result is > not null and this both catches errors and reminds the > programmer to think about the null case.) Couldn't agree more. > > Nevertheless, deRefStablePtr should raise an exception when it finds > > an invalid stable pointer. > > Which brings me back to my question: _which_ exception should > it raise? Either 'ErrorCall "Foreign.StablePtr.deRefStablePtr: invalid stable pointer"', or a new exception. I don't mind which. Cheers, Simon

2 1

hs_garbage_collect
by Alastair Reid 12 Jun '02

12 Jun '02

I'd like to extend the set of functions that a Haskell system provides to C programs. As well as hs_init, hs_exit and hs_set_argv, I'd like to have: int hs_garbage_collect( int how_hard ); This invokes the Haskell garbage collector. The argument and result are for use when interacting with generational collectors. The result is 0 if the garbage collector has done a full GC. Increasing the size of the argument provides greater and greater encouragement to do a full GC. Thus, this loop int i=0; while (hs_garbage_collect(i++)) {} is guaranteed to terminate when further GC calls will not free up any more objects. Subtleties: 1) What happens if the programmer writes this code instead: int i=10; while (hs_garbage_collect(i++)) {} ^^ start deeper It can either behave the same as if they started at 0 or it can start by doing a hefty GC or whatever it feels like. All that matters is that increasing the value of how_hard makes more GC happen. What if they write the loop backwards: int i=10; while (hs_garbage_collect(i--)) {} ^^ start deeper ^^ decrement They'll start with a hefty collection and then do increasingly small collections. The subsequent (smaller) collections might not even achieve anything but they will still return zero only if there is no more garbage to be collected. 2) On a distributed Haskell implementation, increasing the value of how_hard must eventually cause remote machines to do a GC too. 3) It might seem simpler to just have hs_garbage_collect do a full collection. But this would give no efficient way to write code that garbage collects until enough C objects have been released. Using the above interface this would be: int freespace; void free(void* object, int size) { freespace += size; raw_free(object); } void* alloc(int requirement) { int i=0; while (freespace < requirement) { if (hs_garbage_collect(i++) == 0) { return 0; // fail } } return raw_alloc(requirement); } 4) Increasing the value of how_hard must eventually cause all ForeignPtr finalizers for free objects to be invoked. i.e., GHC would have to keep track of whether there are any runnable finalizer threads and run them to completion. Because we want to garbage collect no more than we have to, we might want the how_hard argument to behave as follows: if there are any pending finalizers, run one of them; otherwise do either a big or small collection. // Note that this version ignores the how_hard argument // but will behave correctly anyway. int hs_garbage_collect(int how_hard) { static next_depth = 0; if (pending_finalizers > 0) { // finalize what we can run_one_finalizer_to_completion(); return 1; } if (next_depth == 0) { minor_garbage_collect(); next_depth = 1; return 1; } else { major_garbage_collect(); next_depth = 0; return (pending_finalizers > 0); } } -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/ ps Was there any consensus about changing the hs_init API as sugegsted last week?

1 0

RE: deRefStablePtr exception?
by Simon Marlow 12 Jun '02

12 Jun '02

> What exception does deRefStablePtr raise when handed an invalid > pointer such as 0? That's a good point, I don't think it has any error checking at all. Of course the only way to get an invalid stable pointer is by calling freeStablePointer on a valid one, or by using the FFI. Nevertheless, deRefStablePtr should raise an exception when it finds an invalid stable pointer. Cheers, Simon

2 1