- FFI - Haskell.org

RE: Threaded RTS Patch
by Simon Marlow 27 Jan '03

27 Jan '03

> I haven't read Hans Boehm's paper (but will try to get a > copy once I am off this plane and have a decent Internet > connection again). While I understand the problems of > running finalizers at program exit, I think the OS plus > explicitly-called-clean-up-routine argument doesn't always > work either. An explicitly called clean up routine doesn't > help when a program terminates abnormally. Using exception handlers, you can catch most kinds of abnormal terminations and call your cleanup routines. The kinds that you can't catch are: - heap overflow. That's a difficiency that we should fix. - RTS internal errors. It is unlikely that cleanup routines will be able to run after a RTS internal error anyway. - Other termination conditions, none of which we would be able to run finalizers under: signals/process kills, power failure, etc. - Deadlock, which should be handled by time-outs in any robust system. So I submit that under all reasonable error conditions it is possible to ensure that cleanup routines get to run. GHC uses this method to delete its temporary files, BTW (and it's currently a bug that a heap overflow in GHC will cause temporary files to be left lying around). Admittedly, exceptions aren't properly a part of H98 + FFI. But I think we can agree that this is generally a direction that we should be moving in; Hugs now has exception support that matches GHC's, and the implementation cost isn't that high for other Haskell implementations. Cheers, Simon

1 0

Kobilere Uzman Meslek Guruplar�na F�rsatlar
by E-OF�ST�RK�YE 26 Jan '03

26 Jan '03

1 0

More hot deals-cheapes Jap Hentai Anime DVDs....check it out.
by Cheap Jap Hentai Anime DVDs 25 Jan '03

25 Jan '03

Check out one of the best kept secret of ebay. I have found the cheapest Jap hentai anime dvd there. check it out: http://cgi6.ebay.com/ws/eBayISAPI.dll?ViewSellersOtherItems&userid=rkwexcit… If you got this by mistake, please allow us to remove you name from our mailing list. Please contact remove(a)2serviceher.com

1 0

Re: Threaded RTS Patch
by Manuel M T Chakravarty 24 Jan '03

24 Jan '03

[I have redirected this to the FFI list, being our favourite finalizer battleground] "Simon Peyton-Jones" <simonpj(a)microsoft.com> wrote, > | For now, I resolved the finalizer issue by making the finalizers > behave > | approximately as in the non-threaded case. > | When the main action finishes, all finalizers are run one after > another > | (but in unspecified order), then the program exits. While the > | finalizers are being run, other haskell threads _continue to run_. > This > | seems ugly and dangerous to me, but a) it is the same in the > | non-threaded RTS and b) it's non-trivial to do it differently. > > Hans Boehm (the world expert on this kind of stuff) gave a good talk at > POPL about finalizers. His paper "Destructors, finalizers and > synchronisation" is doubtless somewhere on the web; certainly it's in > the POPL proceedings. > > He argues strongly that > > there should be no system guarantee that > finalizers are run on program exit > > His main reason is that there can be absolutely no guarantees about > ordering, so even if the finalizer wants to print something out, for > example, the stdout handle might have been closed. Finalizers that just > close open file handles aren't much of an improvement: the OS cleans up > anyway. Finalizers that do more are hamstrung by not knowing what else > has been finalized first. > > He argues, too, that the programmer can control this stuff himself, by > running an explicitly-called clean-up routine to release external > resources (if that is needed). > Weak pointers can ensure that this clean-up routine does not keep the > resource alive. I haven't read Hans Boehm's paper (but will try to get a copy once I am off this plane and have a decent Internet connection again). While I understand the problems of running finalizers at program exit, I think the OS plus explicitly-called-clean-up-routine argument doesn't always work either. An explicitly called clean up routine doesn't help when a program terminates abnormally. Regarding the OS, it's fine for classic OS resources, such as file handles, but when middleware-ish services are involved, they may not be automatically notified of the demise of a process by the OS. I guess, it might be argued that such services, which are often network-based, need to be able to cope with unexpected failures etc anyway. The point about flushing resources has already been made. Just to support it with an application. If I write a log file in my application, I want all log messages flushed to disk on termination especially if the program terminates abnormally (where I haven't got a chance to call the flush routine explicitly). Such a flushing function needs to be extra careful when making use of other resources (which may or may not have been finalized yet), but I think we should provide the means to implement it. However, it may be sufficient to require "best effort" instead of a guarantee that all finalizers run. In the case of clean ups, we can't be definite about what happens in the case of an unexpected failure anyway, but we might want to arrange for a good outcome (eg, the log file gets flushed) whenever possible. Cheers, Manuel

1 0

Finalizers: conclusion?
by Simon Marlow 23 Jan '03

23 Jan '03

Ok, I'm sad to say that the problem we recently uncovered to do with finalizers sharing values with the rest of the program essentially kills off the possibility of doing Haskell finalizers in systems without proper concurrency support. I'm rather embarassed that I didn't notice this before; sorry for wasting everyone's time :-( Let's keep C finalizers for the FFI spec. In GHC I imagine we'll continue to offer Haskell finalizers as an extension, but I haven't decided on an interface yet (suggestions welcome). >From now on I intend to keep track of a strict quota that prevents me from writing more email than code :-) Cheers, Simon

6 8

ANN: H98 FFI Addendum 1.0, Release Candidate 8
by Manuel M T Chakravarty 22 Jan '03

22 Jan '03

I put a snapshot of the current status of the FFI Addendum as RC8 at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ Despite there still being two unfinished discussion threads, I felt that it is time for another RC, as many people probably don't track the progress in CVS. Cheers, Manuel -=- % 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.

2 1

White space in ccall impents
by Ian Lynagh 22 Jan '03

22 Jan '03

Is it just me or does the FFI spec not explain what whitespace is needed between the components of the ccall impent? 4.1.1 is the obvious place for it to be. In particular, even after reading between the lines, questions like "are multiple spaces between static and fname allowed", "is a space between & and cid allowed (or required)" and "are tabs allowed" seem to remain unanswered. Thanks Ian

3 5

["Simon Marlow" <simonmar@microsoft.com>] RE: cvs commit: fptools/libraries/base/Foreign ForeignPtr.hs
by Alastair Reid 22 Jan '03

22 Jan '03

[Thread moved from the library cvs mailing list] Simon Marlow: > - Fix the Eq instance for ForeignPtr to match the behaviour > specified by the spec. Two ForeignPtrs are equal iff their > underlying Ptrs are equal (previously they were equal iff they were > the same ForeignPtr). Alastair Reid: > Hmmm, the Hugs implementation goes for 'same foreignptr' and, to me, > that seems to make more sense. > > I wonder why the spec changed the semantics from that in the > Hugs-GHC spec? Simon Marlow: > I don't have any strong opinions on the matter, I just changed it to > match the spec because someone complained. > > Do you have an example where the previous behaviour is more useful? > Perhaps it should be brought up on the FFI list. I don't have a really compelling example just a nagging feeling and worry that a design is being changed without (as far as I can recall) any discussion of the matter. Here's some questions that might help understand the difference: 1) Is there any practical difference between the old semantics and the new? There used to be a big difference because ForeignObjects supported an operation to replace the underlying Ptr. Equality on mutable objects is clearly different from equality on the contents of the mutable objects. But, ForeignPtrs with the same Ptr but different finalizers are different and the finalizer list _is_ mutable so there is a useful difference. The difference between two ForeignPtrs which contain the same Ptr is especially clear if we think about what happens if the first one dies before the second or the second is the first to die. 2) Can either semantics be implemented in terms of something we already have? We can implement the new semantics using castForeignPtrToPtr. There's no way to implement the old semantics using other existing operations. Even if there was a way to extract the list of finalizers (and assuming we're happy using pointer equality on the finalizer functions), we still couldn't implement it because ForeignPtrs are, effectively, mutable objects. In short, I can see that switching to the new semantics (ForeignPtr equality == equality of contents) removes something we had before and doesn't add anything new but I don't have any examples of where it is actually useful. (I also have no examples of where the new semantics is useful.) I should also say that I have no strong feelings on the matter - I'd just like to hear someone argue that the change is an improvement or be pointed at an old discussion on the subject. -- Alastair

4 7

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