January 2003 - FFI - Haskell.org

Finalizers finalized
by Manuel M T Chakravarty 22 Jan '03

22 Jan '03

Sorry for taking so awfully long with a wrap up of the finalizer affair, but here it is. Unanimous agreement: * Alastair was right: Haskell finalizers require pre-emptive concurrency => C-finalizers only in FFI 1.0 Still under discussion: * Names for the C-finalizer functions: - A number of people have called for names other than those originally used for Haskell finalizers; in particular, an inclusion of the word "unsafe" was proposed. - Two important points have been ignored in this part of the discussion: (1) FFI RC 6 already included C finalizers *and* used the original names (`newForeignPtr' and `addForeignPtrFinalizer') after we discussed this point before. (2) Hugs Nov2002 already implements the FFI RC 6 API. Alastair mentioned that before the release and shortly after it was discovered that Haskell finalizers won't make it into the FFI spec. I think we owe it to the Hugs people to stick to `newForeignPtr' and `addForeignPtrFinalizer' now. Besides, I also think that these names are better. As Alastair mentioned, these are the only finalizer primitives in the FFI, so it is a bit strange if they are labeled unsafe. Please also note that the unsafeness is different from that in other functions that contain the word "unsafe" (like `unsafePerformIO'). Hence, I don't think it would really make the meaning clearer and being more precise in the names would make them pretty long. Proposed action: leave the names as published in FFI RC 6 * Alastair proposed the addition of void hs_free_stable_ptr (HsStablePtr x); The name is consistent with the rest of the FFI C API and has already been included into Hugs Nov2002. Moreover, Sven already added void hs_free_stable_ptr (HsStablePtr *sp); void hs_free_fun_ptr (HsFunPtr *fp); to the CVS version of the spec a while ago. I am not sure whether the "*" in the signatures was a mistake. Maybe the idea was to pass a pointer to the pointer that is to freed in and have the freeing function set that to 0L. However, I think, it is better to go with the interface suggested by free() and already implemented in Hugs. Proposed action: Add void hs_free_stable_ptr (HsStablePtr sp); void hs_free_fun_ptr (HsFunPtr fp); to the spec. [NB: Sven already added the functions with the "*" in the signature to GHC's `HsFFI.h'. These would need to change.] * Should there be a guaranteed execution order for multiple finalizers on a single object? Alastair argues for this in http://haskell.org/pipermail/ffi/2002-November/000990.html There have neither been positive nor negative comments. Proposed action: Revise the spec for `addForeignPtrFinalizer' to read as attached below. * `touchForeignPtr', `keepAlive', and `ForeignDependency': To be honest, I don't buy into the motivation for `keepAlive' and friends from http://haskell.org/pipermail/ffi/2002-October/000942.html I'll state my reasons in a direct reply to the above message. Proposed action: leave `touchForeignPtr' as it is in FFI RC 6 * The `Proxy' story: The discussion seemed to have trailed off without a real conclusion. I'll write a seperate email on this. Any *serious* objections? (I already executed the above proposed actions on the CVS version of the spec.) Cheers, Manuel -=- \item[addForeignPtrFinalizer ::\ ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO ()] Add another finalizer to the given foreign pointer. All finalizers associated with a single foreign pointer are executed in the opposite order of their addition---i.e., the finalizer added last will be executed first.

4 6

Re-exporting modules in the Foreign hierarchy
by Sven Panne 21 Jan '03

21 Jan '03

Yet another change request for the FFI libraries: For reasons of consistency, I propose to introduce an intermediate module Foreign.Marshal, which re-exports the modules: Foreign.Marshal.Alloc Foreign.Marshal.Array Foreign.Marshal.Error Foreign.Marshal.Pool Foreign.Marshal.Utils While I'm at it: What was the reason for the decision that Foreign.C re-exports Foreign.C.Types Foreign.C.String Foreign.C.Error but not Foreign.C.TypesISO? If there wasn't a good one, I propose to add this for consistency again. It would be nice if modules exported at least all the ones directly below them in the hierarchy. Cheers, S.

3 2

Re: Proposal: Pooled memory management
by Sven Panne 21 Jan '03

21 Jan '03

Manuel wrote: > [...] > * I want to get v1.0 of the spec fixed. We are really only > in bug fix mode for quite a while and only the finalizer > problems held us back from finishing the spec. That's OK and I understand your motivation. Let's finish v1.0 first. > * I am sure there are plenty more useful FFI-related > libraries. However, the initial plan was to define basic > functionality on top of which more elaborate schemes can > be implemented. We need to draw the line somewhere. [...] But I strongly disagree here: The initial plan was to make a very small, but sufficient addition to the language (=> foreign import/export), which can be implemented easily on existing systems. In this respect, we have reached our goal quite elegantly IMHO. The related libraries are a totally different beast: Minimality is *not* a design goal here. Otherwise we might be happy with e.g. Foreign.Marshal.Alloc.mallocBytes Foreign.Marshal.Alloc.allocaBytes Foreign.Marshal.Alloc.reallocBytes Foreign.Marshal.Alloc.free Foreign.Marshal.Util.copyBytes Foreign.Marshal.Util.moveBytes alone. Or another example: Why should we include such trivialities like Foreign.Marshal.Error.void or Foreign.Marshal.Util.toBool in the FFI spec? Minimality? Possibility of a lightning-fast special implementation? Definitely not. The basic task of a library (or a collection of related libraries) is to establish a common "language" and make common notions (like scoped or pooled allocations) explicit. Looking at the OO world, that's the reason for all this pattern hype. In a nutshell: Let's include as many useful "patterns" in the next FFI spec versions as possible! Otherwise we might talk the same language without recognizing it... Cheers, S.

2 1

RE: Proposal: Pooled memory management
by Simon Marlow 21 Jan '03

21 Jan '03

> Manuel wrote: > > [...] > > * I want to get v1.0 of the spec fixed. We are really only > > in bug fix mode for quite a while and only the finalizer > > problems held us back from finishing the spec. > > That's OK and I understand your motivation. Let's finish v1.0 first. I agree, but I don't have any problem with forking the spec at this point. The changes to the current 1.0 RC are going to be very small from now on. > In a nutshell: Let's include as many useful "patterns" in the > next FFI spec > versions as possible! Otherwise we might talk the same > language without recognizing it... So we might well ask what useful new functionality is provided by a pool-style memory manager. One feature is performance: compared to using malloc/free, a pool is going to be much cheaper. But I'd be interested to compare the performance you get from using pools to GHC's implementation of mallocForeignPtr, which also sidesteps malloc/free to get decent performance. Compared to mallocForeignPtr, there are some qualitative differences which might make one or the other more convenient in some situations: - mallocForeignPtr provides garbage-collected storage. No need to free the storage later. - However, you do need to use withForeignPtr to get access to the object. This can be quite annoying. So, assuming the performance is roughly the same (I'm guessing that using pools may be slightly faster than mallocForeignPtr, but not significantly), do people see any other compelling reasons to be using pools? GHC's runtime has an Arena abstraction which is an implementation of pool-style memory management, and could be used to implement Pools, BTW. Cheers, Simon

3 2

Proposal: Pooled memory management
by Sven Panne 20 Jan '03

20 Jan '03

The FFI libraries currently contain support for explicit allocation and deallocation via the malloc/free family and support for implicit allocation and deallocation via alloca and friends. But there is a very useful level between these extremes: Pooled memory management. Under this scheme, (re-)allocations belong to a given pool, and everything in a pool is deallocated when the pool itself is deallocated. You can find the implementation and the (lean) docs at: http://haskell.org/HOpenGL/PoolRFC/Pool.hs http://haskell.org/HOpenGL/PoolRFC/html/Foreign.Marshal.Pool.html I propose adding this module to FFI addendum and the exports of module Foreign.Marshal. Although the module is definitely not a candidate for the next ACM award, it's a useful and common abstraction which can easily be implemented on the existing FFI modules. Comments? Cheers, S.

3 5

alignment
by Ross Paterson 14 Jan '03

14 Jan '03

Two additions I think are required: 1) The spec should state that mallocBytes and allocaBytes return a block of memory sufficiently aligned for any of the primitive types supported by the architecture. 2) The description of Storable should require sizeOf x `mod` alignment x = 0 The library implementation of mallocArray implicitly assumes this, and C also requires that elements of an array are allocated contiguously.

3 4

Foreign proxy
by Manuel M T Chakravarty 13 Jan '03

13 Jan '03

An interface like the following has been repeatedly proposed (in slightly varying versions): data ForeignObj a -- abstract instance Eq (ForeignObj a) type Finalizer a = FunPtr (a -> IO ()) newForeignObj :: a -> Finalizer a -> IO (ForeignObj a) addFinalizer :: ForeignObj a -> Finalizer a -> IO () withForeignObj :: ForeignObj a -> (a -> IO b) -> IO b touchForeignObj :: ForeignObj a -> IO () If we adopt it, we might define `ForeignPtr' in terms of the new interface: type ForeignPtr a = ForeignObj (Ptr a) newForeignPtr :: a -> Finalizer (Ptr a) -> IO (ForeignPtr a) <etc> We, btw, also need foreignObjToObj :: ForeignObj a -> a to implement `foreignPtrToPtr'. Unfortunately, there doesn't seem to be any easy way to implement `castForeignPtr', which is valid for pointers, but can't be generalised to `ForeignObj'. We could assume the position that such casts need always to be made on the vanilla `Ptr' after it has been obtained from the `ForeignPtr'. However, this might be a nuisance in some situations. Open Questions ~~~~~~~~~~~~~~ (1) Shall we adopt an interface like `ForeignObj'? (Seems like a nice idea to me.) (2) What shall we do about `castForeignPtr'? (3) Shall we call the new objects `ForeignObj'? (It's a good name, but conflicts with some of GHC's legacy libraries. `ForeignProxy' is one of the more appealing possible alternatives that was suggested ealier. `ForeignFinalized' is also nice, but maybe a bit long.) What do you think? Manuel

1 0

lens sipariş
by M. Emin ERDEM 05 Jan '03

05 Jan '03

2 kutu bosh-loumb 66 -4.25 saydam lens istiyorum. m. emin erdem tel. 03682876265-118

1 0

Firmalar İçin En Verimli ve Karlı TİCARET PORTALI Açıldı...
by Neslihan ÇETİN 01 Jan '03

01 Jan '03

Bu mesajın içeriğini düzgün bir şekilde göremiyorsanız, www.e-talep.com/tanitim <http://www.e-talep.com/tanitim> adresini ziyaret edebilirsiniz. <http://www.e-talep.com> _____ Neden ? E-ticaret Neden ? E-talep.com _____ Ticaretin %35'i internete taşınacak, sizde yerinizi alın !!! 2005 yılına kadar firmalar arası ticaretin %35'inin elektronik ortama taşınacağı tahmin edilmektedir. Bir firma çalışanı olarak veya firma sahibi olarak bu gelişmelerin dışında kalmayıp, sizin için tasarlanan ve hizmetinize sunulan E-talep.com gibi ücretsiz teknolojileri çalışma hayatınıza entegre etmelisiniz. E-talep.com ile Firmanız daha hızlı kar edecek Firmaların, Pazarlama ve Satınalma bölümleri için tasarlanan E-talep.com, karlı ticaret ortamı ile satışlarınızda artışa neden olacak, böylece hızlı kar etmenizi sağlayacak. Satın almada ki %15'lere varan fiyat avantajı ile girdi maliyetleriniz azalacak, böylece kar marjınız yükselecektir. E-talep.com ile rekabet gücünüzü ve verimliliğinizi artıracaksınız Tüm kamu ve firma alımlarından veya bizim tabirimizle; güncel taleplerden anında haberdar olacak, rakip firmaların bir adım önüne geçeceksiniz. Ayrıca pazarlama ve satın alımda verimliliği artırarak zaman ve para tasarrufu sağlayacaksınız. Satın alım sırasında %8 ile %15 arası kar edeceksiniz Firmanızın alımlarını e-talep.com üzerinde yayınlayarak, beklemediğiniz fiyat indirimleri ile karşılaşacak, girdi maliyetlerinizi azaltacaksınız. Alımlar sırasında ortalama %8 ila %15 arası kar sağlayacaksınız. Firmalar için zaman çok daha hızlı akıyor Firmaların artık hantal bir yapıyla büyümesi söz konusu değil, artık satacağı ürünleri kısa sürede pazarlamalı, ihtiyaç duyduğu ürünleri ise daha hızlı siparişedip satın almalı. E-talep.com yüksek teknolojisiyle, yatırım yapmanıza ve para harcamanıza gerek kalmadan bu imkanı size sunuyor. E-talep.com ailemizde sizi de görmek istiyoruz Her geçen gün ailemiz büyüyor 2 ay gibi kısa bir sürede 1000 üyeyi aştık, zamanla daha büyüyeceğimiz inancındayız. Ailemize katılarak, küçük ve orta ölçekli firmaların, kamu kurum ve kuruluşlarının oluşturduğu çok geniş bir alıcı ve satıcı kitlesine ulaşacak, yeni iş ortakları edineceksiniz. E-talep.com'un arkasında güçlü bir kadro var E-talep.com firmalar arası ticaret ve bilişim teknolojilerinde uzman olan, profesyonel bir ekip tarafından tasarlandı. Sizlerden gelen öneri ve isteklerle bu ticaret platformu daha da geliştirilerek, kolay kullanılabilir, verimli ve etkin bir ticaret ortamı oluşturulacaktır. E-talep.com Kullanımı kolay güvenli bir ticaret platformudur E-talep.com kullanımı kolay, üyelerin gizlilik kurallarını gözeten, güvenli bir ticaret platformundur. Daha fazla bilgi için; www.e-talep.com <http://www.e-talep.com> adresini ziyaret edin. _____ Görüş, öneri ve sorularınız için; t ı k l a y ı n <http://www.e-talep.com/Pages/Contact.asp> E-posta almak istemiyorsanız; t ı k l a y ı n <mailto:destek@e-talep.com?subject=E-posta almak istemiyorum>

1 0