> Or a simpler operation, > touch :: a -> IO () > which does nothing but ensures that at a given place the object is > alive, i.e. this call cannot be optimized away early as seq could be. > It can be a primop that does nothing for example. Ok, that sounds reasonable. Nice in fact. readIntOfForeignObj fo i = do a <- foreignObjToAddr fo r <- readIntOfAddr a touch fo return r should expand to exactly the same code as the current readIntOffForeignObj primop. If you need internal pointers to a structure pointed to by a ForeignObj, then you'll need an arrangement of weak pointers to guarantee that the outer object is kept alive while the internal pointer is still in use. (actually the internal pointer could be a ForeignObj with a finalizer which just touches the outer object). Ok, so does "touch" sound like the way to go? Cheers, Simon
- Accessing ForeignObj contents from Haskell Marcin 'Qrczak' Kowalczyk
- RE: Accessing ForeignObj contents from Hask... Simon Marlow
- Re: Accessing ForeignObj contents from ... Marcin 'Qrczak' Kowalczyk
- Re: Accessing ForeignObj contents f... Marcin 'Qrczak' Kowalczyk
- Re: Accessing ForeignObj conten... Marcin 'Qrczak' Kowalczyk
- RE: Accessing ForeignObj contents from Hask... Simon Marlow
- RE: Accessing ForeignObj contents from ... Manuel M. T. Chakravarty
- RE: Accessing ForeignObj contents from Hask... Simon Marlow
- Re: Accessing ForeignObj contents from ... Marcin 'Qrczak' Kowalczyk
- Re: Accessing ForeignObj contents f... Manuel M. T. Chakravarty
- RE: Accessing ForeignObj contents from Hask... Simon Marlow
- Re: Accessing ForeignObj contents from ... Keith Wansbrough
- Re: Accessing ForeignObj contents f... Marcin 'Qrczak' Kowalczyk
- Re: Accessing ForeignObj contents from ... Marcin 'Qrczak' Kowalczyk
- Re: Accessing ForeignObj contents f... Manuel M. T. Chakravarty
- Re: Accessing ForeignObj conten... Marcin 'Qrczak' Kowalczyk