- FFI - Haskell.org

Re: freeHaskellFunPtr
by Sven Panne 18 Jun '02

18 Jun '02

Alastair Reid wrote: > This looks fairly delicate [...] Agreed. :-} > It seems like your example could be handled by calling the free > function in the Haskell code that invokes the C code that invokes the > callback: [...] My Haskell callback is actually a one-shot timer callback from GLUT, and I'm not directly "invoking the C code that invokes the callback": After an initial setup phase, *everything* is callback-driven, so your proposal is not a solution here. > How much worse would it be to write your code in this way? Hmmm, it looks like I have to resort to a "global variable" hack for tracking the (un-)registration of other callbacks, anyway. The problem is as follows: If you repeatedly set or clear a Haskell callback, you have to track what the C side already knows on the Haskell side, too, just for freeHaskellFunPtr. :-P The additional problem with those one-shot callbacks is that only the callback knows when to deregister. In a nutshell: I'm not very happy with the explicit allocation and deallocation of the 'foreign import wrapper' thunks. They are an artefact of the Haskell implementations and look strange in an otherwise GC-ed world... Anyway, the documentation of freeHaskellFunPtr should be made a little bit clearer about what we decide. Cheers, S.

2 1

RE: Library archives
by Simon Marlow 18 Jun '02

18 Jun '02

> In conclusion, C is designed to use a single global namespace and > things break if you try to change that. Hence, I don't think the ffi > for C can allow C libraries to export overlapping names. I think the > ffi spec should explicitly say that all C libraries are loaded into a > single global namespace. And I don't think the square bracket part > can be treated like a Haskell qualified name. Agreed. The library spec part of an FFI declaration is not indended to replace the specification of libraries by command-line options or packages. We had a long discussiong about this a while back (sorry for sounding like a broken record!), where some people argued that libraries should be specified in the FFI declaration in the source code, and some people (inc. me) argued that libraries should be kept out of the source code altogether, on the grounds that they were too system-dependent and it would be impossible to write portable code without resorting to CPP. There were other reasons, but I can't remember them all now. > 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'd be delighted if Hugs adopted a package system similar to GHC's - we even considered that possibility by including a field in the package spec for specifying where source code for a package lives (which is unused by GHC). I'd be surprised if GHC's package system couldn't be used relatively unchanged in Hugs. All you need to do is: - on starting Hugs, read a package config file (unfortunately I guess you'll need a yacc parser for that) - augment the search path with directories from packages specified on the command line (the source_dirs field of the package spec) - dlopen() libraries from packages (the extra_libraries field of the package spec). Cheers, Simon

2 1

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