- FFI - Haskell.org

Allocation & Marshalling Question (again)
by Adrian Hey 30 May '03

30 May '03

Hello, Judging by the silence that greeted my last posts re this a couple of weeks ago I suspect this is of no interest to anyone but me :-( An extra couple of weeks cogitation on this hasn't really changed MHO much (other than I'm no longer so pessimistic about the safety of my <+ operator). Seeing as the FFI seems to be close to finalization I thought I'd have another go. So excuse me if this seems half baked, but am I the only one who thinks the type signatures of utilities like this.. allocaBytes :: Int -> (Ptr a -> IO b) -> IO b ..are rather inconvenient? Wouldn't.. allocaBytes :: Int -> (Ptr a -> b) -> b ..be more useful? To get around this I defined an operator.. infixl 0 <+ (<+) :: (Ptr a -> b) -> ((Ptr a -> IO b) -> IO b) -> b f <+ alloc = unsafePerformIO $ alloc $ \p -> return $ f p (Actually I now think the type of <+ should be.. (<+) :: (a -> b) -> ((a -> IO b) -> IO b) -> b ..so it will work with functions like withCStringLen) This seems to work, but I wasn't entirely comfortable with its safety due to the use of unsafePerformIO. Anyway, perhaps there's a good reason for things having been done this way, but right now I can't see it. So could somebody who understands the reasons for the FFI design decisions and underlying implementation explain why a change such as I have suggested could not or should not be made? Possible explanations that occur to me are.. 1- It's technically impossible. 2- It's unnecessary because FFI users can define their own contraptions like <+ if they want them, assuming the use of unsafePerformIO in this context really is safe (and unsafePerformIO is available). 3- It's undesirable because the existing forms are better in some way. 4- It's undesirable because it would break existing code (not true AFAICS). Thanks -- Adrian Hey

3 8

ffi@haskell.org
by sms 29 May '03

29 May '03

1 0

RE: Allocation & Marshalling Question (again)
by Simon Marlow 29 May '03

29 May '03

> On Wednesday 28 May 2003 10:32, Simon Marlow wrote: > > > Even in GHC where we use garbage collected memory instead > of malloc, we > > still make use of the IO monad to control the lifetime of > the allocated > > memory. > > Thanks for that info. I'm not to clear about what the > intended implementation > is (if there is one) from reading the FFI spec. It seems to > me that if the > IO monad is used to control the lifetime you could use stack > allocation quite > easily. (Dunno if that would be any more efficient for the > ghc rts though.) > Using the garbage collected heap but not actually using normal garbage > collection mechanisms seems a bit strange to me :-) I actually thought long and hard about how to implement allocaBytes efficiently in GHC, before eventually coming up with the current scheme. The problem with using stack allocation is that stacks move around in GHC, and you need stable storage for allocaBytes because it passes the pointer to a foreign call. You could use a separate, stable, stack, but then you also need to move the stack pointer back down at the end of the alloca, and that needs to be done in an exeception-safe way, which is also expensive. The current idea is to use a pinned, but garbage-collectable allocation. The pinned object is "touched" at the end of the alloca to ensure that it cannot be garbage collected until then. We don't need an exception handler: if an exception is raised in the middle of the alloca, then the pointer to the object will be simply dropped and the memory garbage collected. Cheers, Simon

1 0

RE: Allocation & Marshalling Question (again)
by Simon Marlow 29 May '03

29 May '03

> Judging by the silence that greeted my last posts re this a > couple of weeks > ago I suspect this is of no interest to anyone but me :-( > > An extra couple of weeks cogitation on this hasn't really > changed MHO much > (other than I'm no longer so pessimistic about the safety of > my <+ operator). > > Seeing as the FFI seems to be close to finalization I thought I'd have > another go. So excuse me if this seems half baked, but am I > the only one who > thinks the type signatures of utilities like this.. > allocaBytes :: Int -> (Ptr a -> IO b) -> IO b > ..are rather inconvenient? > > Wouldn't.. > allocaBytes :: Int -> (Ptr a -> b) -> b > ..be more useful? I haven't thought about this too hard, but it seems "technically difficult" if not "technically impossible". In an implementation which uses a foreign call to malloc to implement allocaBytes, then there has to be a reliable way to ensure that the memory is deallocated later. If we're not in the IO monad, then I can't see how to do this. Even in GHC where we use garbage collected memory instead of malloc, we still make use of the IO monad to control the lifetime of the allocated memory. Cheers, Simon

2 1

RE: H98 FFI Addendum 1.0, Release Candidate 10
by Simon Peyton-Jones 26 May '03

26 May '03

The bound-threads story interacts with the FFI -- indeed, it's in a document in Haskell-report/ffi/threads.tex. Do we ultimately plan to fold it into the FFI spec (but, awkwardly, it must speak of concurrency)? Or do we ultimately plan to have a separate "blessed appendix" on concurrency generally? And if the latter, who would like to edit it? Manuel has done a great job with the FFI spec; I doubt concurrency will be half as hard. Simon | -----Original Message----- | From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Manuel M T | Chakravarty | Sent: 22 May 2003 22:33 | To: haskell(a)haskell.org | Subject: ANN: H98 FFI Addendum 1.0, Release Candidate 10 | | Dear Haskell Folks, | | Release Candidate 10 of the H98 FFI Addendum 1.0 is now | available from | | http://www.cse.unsw.edu.au/~chak/haskell/ffi/ | | The change log since RC 7, which was the last version | circulated via haskell(a)haskell.org, is appended below. | | Please review this specification carefully. If no | suggestion that leads to a serious change is made within two | weeks, I will freeze version 1.0. | | Thanks, | Manuel | | -=- | | Changes since RC9: | * 1: Mentioning interaction with foreign threads as an open problem. | * 2 & 3: Removed `threadsafe' again, as the proposal for thread support is | still evolving and it is not yet clear whether a new safety level | is required. | * 5.5: Added the type synonym `FinalizerPtr' and rewrite the documentation | of finalizers. | * 5.6: Clarified the description of `StablePtr' | * 5.8: Added `finalizerFree' | * 6.2: All the types in CTypes must be newtypes that are exported | abstractly. | | Changes since RC8: | * 5.8: `MarshallAlloc.reallocBytes' is no longer permitted on memory | allocated with `alloca' or `allocaBytes'. | * 6.1: Deinitialisation of the RTS via `hs_exit()' followed by | (re)initialisation with `hs_init()' must be supported. | | Changes since RC7: | * Clarified the lexis of C identifiers and C header file names | * In `ForeignPtr', added `mallocForeignPtrArray' and `mallocForeignPtrArray0' | * Clarified spec of allocations functions adding constraints taken from the | corresponding C routines | * `mallocBytes' and `allocaBytes' must align memory sufficiently for any | basic foreign type that fits into the allocated block | * Removed typos in the description of the module `ForeignPtr' | * Added Peter Gammie to the list of acknowledged people | * `addForeignPtrFinalizer' guarantees that finalizers for a single foreign | pointer are executed in the opposite order as they were added. | * `Storable': Require that the size is divisible by the alignment | * Added Ross Paterson to the list of acknowledged people | * Added hs_free_fun_ptr() and hs_free_stable_ptr() | * Changed order of arguments of `mkIOError' and `annotateIOError' to match | with the current implementation in GHC's FFI libraries. | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

2 1

RE: H98 FFI Addendum 1.0, Release Candidate 10
by Simon Marlow 23 May '03

23 May '03

I've been meaning to write up an addendum on Concurrency for a while, but haven't got around to it. That's not to say I hold a lock on it; if anyone else wishes to tackle it then by all means go ahead, and I'll try to help out where possible. Cheers, Simon > -----Original Message----- > From: ffi-admin(a)haskell.org [mailto:ffi-admin@haskell.org] On > Behalf Of Simon Peyton-Jones > Sent: 23 May 2003 08:42 > To: chak(a)cse.unsw.edu.au; ffi(a)haskell.org > Subject: RE: H98 FFI Addendum 1.0, Release Candidate 10 > > The bound-threads story interacts with the FFI -- indeed, it's in a > document in Haskell-report/ffi/threads.tex. Do we ultimately plan to > fold it into the FFI spec (but, awkwardly, it must speak of > concurrency)? Or do we ultimately plan to have a separate "blessed > appendix" on concurrency generally? And if the latter, who would like > to edit it? Manuel has done a great job with the FFI spec; I doubt > concurrency will be half as hard. > > Simon > > | -----Original Message----- > | From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On > Behalf Of Manuel M T > | Chakravarty > | Sent: 22 May 2003 22:33 > | To: haskell(a)haskell.org > | Subject: ANN: H98 FFI Addendum 1.0, Release Candidate 10 > | > | Dear Haskell Folks, > | > | Release Candidate 10 of the H98 FFI Addendum 1.0 is now > | available from > | > | http://www.cse.unsw.edu.au/~chak/haskell/ffi/ > | > | The change log since RC 7, which was the last version > | circulated via haskell(a)haskell.org, is appended below. > | > | Please review this specification carefully. If no > | suggestion that leads to a serious change is made within two > | weeks, I will freeze version 1.0. > | > | Thanks, > | Manuel > | > | -=- > | > | Changes since RC9: > | * 1: Mentioning interaction with foreign threads as an open > problem. > | * 2 & 3: Removed `threadsafe' again, as the proposal for thread > support is > | still evolving and it is not yet clear whether a new safety > level > | is required. > | * 5.5: Added the type synonym `FinalizerPtr' and rewrite the > documentation > | of finalizers. > | * 5.6: Clarified the description of `StablePtr' > | * 5.8: Added `finalizerFree' > | * 6.2: All the types in CTypes must be newtypes that are exported > | abstractly. > | > | Changes since RC8: > | * 5.8: `MarshallAlloc.reallocBytes' is no longer permitted on memory > | allocated with `alloca' or `allocaBytes'. > | * 6.1: Deinitialisation of the RTS via `hs_exit()' followed by > | (re)initialisation with `hs_init()' must be supported. > | > | Changes since RC7: > | * Clarified the lexis of C identifiers and C header file names > | * In `ForeignPtr', added `mallocForeignPtrArray' and > `mallocForeignPtrArray0' > | * Clarified spec of allocations functions adding constraints taken > from the > | corresponding C routines > | * `mallocBytes' and `allocaBytes' must align memory sufficiently for > any > | basic foreign type that fits into the allocated block > | * Removed typos in the description of the module `ForeignPtr' > | * Added Peter Gammie to the list of acknowledged people > | * `addForeignPtrFinalizer' guarantees that finalizers for a single > foreign > | pointer are executed in the opposite order as they were added. > | * `Storable': Require that the size is divisible by the alignment > | * Added Ross Paterson to the list of acknowledged people > | * Added hs_free_fun_ptr() and hs_free_stable_ptr() > | * Changed order of arguments of `mkIOError' and `annotateIOError' to > match > | with the current implementation in GHC's FFI libraries. > | _______________________________________________ > | Haskell mailing list > | Haskell(a)haskell.org > | http://www.haskell.org/mailman/listinfo/haskell > > > _______________________________________________ > FFI mailing list > FFI(a)haskell.org > http://www.haskell.org/mailman/listinfo/ffi > >

1 0

RE: H98 FFI Addendum 1.0, Release Candidate 9
by Simon Peyton-Jones 21 May '03

21 May '03

| There is only one open question: What to do about | "threadsafe"? In the threads discussion, there seemed to be | a tendency to not distinguish between "threadsafe" and | "safe" after all. Shall we remove "threadsafe" from 1.0? | That's what I tend to and will do unless there are strong | arguments to retain "threadsafe". I agree. S

1 0

finalizers again
by Ross Paterson 21 May '03

21 May '03

Did we agree that Foreign.Marshal.Alloc whould provide finalizerFree :: FunPtr (Ptr a -> IO ()) (or some other name) corresponding to free, for use as an argument to newForeignPtr?

2 1

RE: architecture-dependent types
by Simon Marlow 21 May '03

21 May '03

> Should not Foreign.C.Types, Foreign.C.TypesISO and System.Posix.Types > export their types opaquely? That would make their interface and > documentation architecture-independent. The FFI doesn't explicitly specify whether these types should be exported abstractly or not, but it does say in section 6.2: "... all types exported by \code{CTypes} are represented as type synonyms or \code{newtype}s of basic foreign types ..." we should really decide one way or the other, since this ambiguity will lead to non-portable differences between implementations of CTypes (and hence Foreign.C.Types). Having the types be opaque sounds reasonable to me, and similarly for System.Posix.Types. Cheers, Simon

2 1

BU FIRSATTAN YARARLANIN.
by Erotik Market 15 May '03

15 May '03

DIKKAT VIDEO CD : Iddia ediyoruz.. Hic bir yerden temin edemeyeceginiz ses ve g�runtu kalitesi ile yuzlerce porno video CD. arSivimiz yenilenmistir. istemis oldugunuz video CD.ler bire bir yollanir kesinlikle isteginiz harici alakasiz baSka video CD.ler yollanmaz. Anal. Oral. Vajinal. Grup. Zenci. FethiS. Ayak fethiS. Gay. Zenci gay. Trans. Transexual. Animal, Lezbiyen ve T�rk daha bircok ceSit ....Ayrica Unlu taninmis porno yildizlari Rocco & silvia saint http://www.erotik.sites.cc/ ZENGIN URUN CESITLERIMIZ : Sisme Bebekler ............... (Erkek & Bayan) Kesinlikle size hayir demeyecek. Vibrat�rler ..................... Istediginiz boy ve ebatlarda (Vajinal/Anal/catal.Pilli.Motorlu.TitreSimli) Suni Vajinalar ................. Asla gerceginden ayirt edemeyeceksiniz (Gercek ten hassasiyetinde) Reailistik Penisler........... Gercek ten hassasiyetinde ve dokusunda (Vantuzlu/Deri kemer kilotlu) Vakum Pompalari ......... Ereksiyonu kolaylastirici ve duzenli kullanimlarda peniste irilesme saglar. Geciktiriciler ................. Erken boSalmayi dert etmeyin (Sprey ceSitleri/Kremler) Kremler ....................... Anal ve Vajinal iliSkilerde kullanabileceginiz kayganlaStirici krem ceSitleri Uyandiricilar ............... Cinsel istek uyandirici haplar ve damlalar. Yapmaniz gereken tek Sey http://www.erotik.sites.cc/ TIKLAMAK .. NOT : BU MAIL REKLAM AMAcLI OLUP HIcBIR SEKILDE TARAFIMIZDA KAYDINIZ BULUNMAMAKTADIR. ILGI ALANINIZIN DISINDA ISE EGER LUTFEN DIKKATE ALMAYINIZ TESEKKURLER..

1 0