- Glasgow-haskell-users

RE: Ptr and ForeignPtr Questions
by Ashley Yakeley 20 Sep '01

20 Sep '01

At 2001-09-20 02:46, Simon Marlow wrote: >No, it's not safe. The reason is that the compiler can track a >ForeignPtr to discover when it dies, in order to run the finalizer, but >it can't track a Ptr. As soon as you drop all references to the >ForeignPtr then the finalizer will run, even if you converted it to a >Ptr and you're still using it. OK, there are different types of safety. The risk here is that the finalisers may have been called by the time you use the Ptr. But if you don't mind that, for instance, if for some reason the finalisers don't render the Ptr invalid, I assume you can still use the Ptr. -- Ashley Yakeley, Seattle WA

1 0

RE: Ptr and ForeignPtr Questions
by Simon Marlow 20 Sep '01

20 Sep '01

> At 2001-09-20 02:14, Simon Marlow wrote: > > >I'll just add that the docs have been updated for 5.02, > > Do you have a URL for that? Not yet, but the release is imminent (really!) so it'll be up on the web site shortly. > >And don't forget that using foreignPtrToPtr is quite dangerous; much > >better to use withForeignPtr instead, otherwise you might find the > >ForeignPtr being finalised earlier than you expect. > > This is because foreignPtrToPtr is not in the IO monad, correct? > > foreignPtrToPtr :: ForeignPtr a -> Ptr a; > > A function like this: > > ioForeignPtrToPtr :: ForeignPtr a -> IO (Ptr a); > ioForeignPtrToPtr fp = withForeignPtr fp return; > > ...would surely be safe? The 5.00 documentation claims that it isn't, > however, but I don't see why. No, it's not safe. The reason is that the compiler can track a ForeignPtr to discover when it dies, in order to run the finalizer, but it can't track a Ptr. As soon as you drop all references to the ForeignPtr then the finalizer will run, even if you converted it to a Ptr and you're still using it. withForeignPtr is safe to use because it ensures that the ForeignPtr is kept live until it returns. The documentation is a little terse on this issue; I'll see if I can improve it. Cheers, Simon

1 0

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 20 Sep '01

20 Sep '01

At 2001-09-20 02:31, I wrote: > int foo (char selector,char* arg) ... > if (selector == 200) I guess that should be int foo (unsigned char selector,char* arg) -- Ashley Yakeley, Seattle WA

1 0

RE: Ptr and ForeignPtr Questions
by Ashley Yakeley 20 Sep '01

20 Sep '01

At 2001-09-20 02:14, Simon Marlow wrote: >I'll just add that the docs have been updated for 5.02, Do you have a URL for that? >And don't forget that using foreignPtrToPtr is quite dangerous; much >better to use withForeignPtr instead, otherwise you might find the >ForeignPtr being finalised earlier than you expect. This is because foreignPtrToPtr is not in the IO monad, correct? foreignPtrToPtr :: ForeignPtr a -> Ptr a; A function like this: ioForeignPtrToPtr :: ForeignPtr a -> IO (Ptr a); ioForeignPtrToPtr fp = withForeignPtr fp return; ...would surely be safe? The 5.00 documentation claims that it isn't, however, but I don't see why. -- Ashley Yakeley, Seattle WA

1 0

RE: Ptr and ForeignPtr Questions
by Simon Marlow 20 Sep '01

20 Sep '01

> Ashley Yakeley <ashley(a)semantic.org> wrote, > > > The documentation for FFI in the GHC user's guide seems to > be out of date > > with regard to passing Ptrs across. > > > > 1. My reference is > > <http://www.haskell.org/ghc/docs/latest/set/ffi.html> > > (from > <http://www.haskell.org/ghc/docs/latest/set/book-users-guide.html>) > > Is this the latest documentation available? > > > > 2. My understanding is that you can use any instance of > 'Storable a => > > Ptr a' as an FFI argument and return type for both imported > and exported > > functions? Is this correct? > > If I understand you question correctly and you want to pass > a pointer to C land and back, yes, this is possible. I'll just add that the docs have been updated for 5.02, and the FFI section now refers to Ptr and ForeignPtr instead of Addr and ForeignObj. > > 4. Does newForeignPtr work safely with null pointers, and will the > > finalizer get called? For instance: > > > > fp <- newForeignPtr nullPtr finalFunc; > > let {isNull = (foreignPtrToPtr fp) == nullPtr}; > > r <- withForeign fp (\p -> foo p); > > > > Will foo be passed nullPtr? Will finalFunc ever get called? > Is my use, > > above, of foreignPtrToPtr safe, and will isNull be True? > > Should work. From the storage managers point of view, a > `Ptr' is just an uninterpreted bit-pattern. A glorified > `Int'. Of course, you should better make sure that > `finalFunc' can handle getting a `nullPtr'. And don't forget that using foreignPtrToPtr is quite dangerous; much better to use withForeignPtr instead, otherwise you might find the ForeignPtr being finalised earlier than you expect. Cheers, Simon

1 0

Ptr and ForeignPtr Questions
by Ashley Yakeley 20 Sep '01

20 Sep '01

The documentation for FFI in the GHC user's guide seems to be out of date with regard to passing Ptrs across. 1. My reference is <http://www.haskell.org/ghc/docs/latest/set/ffi.html> (from <http://www.haskell.org/ghc/docs/latest/set/book-users-guide.html>) Is this the latest documentation available? 2. My understanding is that you can use any instance of 'Storable a => Ptr a' as an FFI argument and return type for both imported and exported functions? Is this correct? What if the type is polymorphic (e.g. declared as 'Storable a => Ptr a' rather than something like 'Ptr Word8')? 3. What about ForeignPtr? Can instances of 'Storable a => ForeignPtr a' be used in FFI? 4. Does newForeignPtr work safely with null pointers, and will the finalizer get called? For instance: fp <- newForeignPtr nullPtr finalFunc; let {isNull = (foreignPtrToPtr fp) == nullPtr}; r <- withForeign fp (\p -> foo p); Will foo be passed nullPtr? Will finalFunc ever get called? Is my use, above, of foreignPtrToPtr safe, and will isNull be True? -- Ashley Yakeley, Seattle WA

2 1

Posix.runProcess
by George Russell 19 Sep '01

19 Sep '01

I think Posix.runProcess should give access to the eventual exit state of the process, if any. Two possible ways: (1) Change its result to IO (IO ExitCode), the inner action being something that waits for the process to complete (without blocking all other threads!) and returns the ExitCode. (Even better would be to make the result just IO ExitCode but this might be too incompatible for people who rely on runProcess returning at once.) (2) If (1) can't be done, change its type to return something similar to Posix.getProcessStatus.

3 4

RE: unsafePtrCompare, anybody?
by Simon Marlow 19 Sep '01

19 Sep '01

> My intuition says that none of the side-effects in my > implementation are > visible from the abstract level of the module. However, the use of > unsafePerformIO certainly modifies the behaviour of the > module. For example, > the following definitions at the beginning of a GHCi session > on the attached > code lead to the subsequent behaviour: > > > foo1 <- return (unsafePerformIO (mkAtom "foo")) > foo2 <- return (unsafePerformIO (mkAtom "foo")) > bar <- return (unsafePerformIO (mkAtom "bar")) > safefoo1 <- mkAtom "foo" > safefoo2 <- mkAtom "foo" > safebar <- mkAtom "bar" > list <- return [safefoo1, safefoo2, safebar, foo1, foo2, bar] These uses of unsafePerformIO really *are* unsafe though :-) Your implementation of mkAtom seems to be similar the the StableName library, in that it has the property that if mkAtom e == mkAtom e', then e == e' but the reverse isn't necessarily true (it may or may not be true). Which is why mkAtom has to be in the IO monad: it has observable non-determinism. FastString works differently: it guarantees that both mkFastString s == mkFastString s' => s == s' s == s' => mkFastString s == mkFastString s' hold. So it is safe for mkFastString to be a pure non-I/O function, because it doesn't have any observable non-deterministic behaviour. Cheers, Simon

1 0

RE: unsafePtrCompare, anybody?
by Simon Marlow 18 Sep '01

18 Sep '01

> One's intuition would suggest that you could be safely > implement mkAtom > without wrapping it in a IO monad. After all, at least at a > abstract level, > an atom table is referentially transparent. The library > documentation says > that lack of side effects and environmental independance is > sufficent to > order for uses of unsafePerformIO to be safe. Is there a > exact (or at least > better) criterion for safety? An exact criterion would require a formal semantics for Haskell, which we don't have. But informally, if a function which is implemented using unsafePerformIO is pure - that is, its result depends only on the values of its arguments and possibly its free variables - then that is a "safe" use of unsafePerformIO. > "unsafePerformIO" is used in the implementation of > mkFastString, so how is it's side effects "safe". It is safe because the side effects aren't visible outside the implementation of mkFastString. HTH, Simon

3 2

RE: unsafePtrCompare, anybody?
by Simon Marlow 18 Sep '01

18 Sep '01

> I'm writing an atom table for a compiler/interpreter, and it > would be really > nice to use unsafePtrLT to implement tree-based finite maps. > > For clarification, my atom table consists of these three functions: > > mkAtom :: String -> IO Atom > show :: Atom -> String > (==) :: Atom -> Atom -> Bool > > such that > mkAtom s >>= (return . show) == return s > and > mkAtom . show == return > and > atom == atom' <=> show atom == show atom' > > mkAtom looks up each string in a table stored in an global > variable, and > returns the atom stored in the table if it is there. > Otherwise, it makes the > string into an atom, inserts the atom into the table, and > returns this new > atom. > > The point of all of this is that now string equality, when > strings are made > into atoms, is just pointer equality, which is available as > IOExts.unsafePtrEq. You might want to check out GHC's FastString module, which does essentially this. We use an explicit hash table, and each FastString has a unique Id for fast comparison. To solve your immediate problem, you could also take a look at the StableName library, which lets you map any old Haskell value on to an Int so you can build finite maps etc. (we use StableNames to build memo tables). There's a small garbage collector overhead for this, though. > Of course, the misuses of unsafePtrEq aren't nearly as > heinous as those of > unsafePtrCompare. On the other hand, it might be next to > impossible to > effectively use unsafePtrCompare in cases that it isn't > completely safe to > use, whereas there are plently of situations where > unsafePtrEq is semi-safe > to use. I can't think of a way to use unsafePtrCompare safely :-) The relative ordering of objects isn't guaranteed to be stable under GC. Cheers, Simon

2 1