January 2003 - FFI - Haskell.org

Repeated hs_init()/hs_exit()
by Simon Marlow 10 Feb '03

10 Feb '03

I'm implementing the latest hs_init()/hs_exit() interface in GHC, and came across an ambiguity or omission in the spec. We're clear that this sequence should be allowed: hs_init(..) hs_init(..) hs_exit() hs_exit() but what about hs_init(..) hs_exit() hs_init(..) hs_exit() That is, should the Haskell system be able to start itself up again after shutting down? It looks like this is desirable from a modularity viewpoint: eg. a C program initialises library A which uses Haskell internally, then de-initialises library A, then initialises library B which also uses Haskell internally. Unfortunately, this is going to require quite a bit of extra work in GHC to get right, and it looks like I'm going to have to examine a lot of code to make sure it is "double-init-safe". Thoughts? Cheers, Simon

4 4

RE: Repeated hs_init()/hs_exit()
by Simon Marlow 29 Jan '03

29 Jan '03

> Just out of curiosity, what would happen if hs_exit were a noop? if it > left haskell initialized? I imagine there would be a space leak if you > expected the rts's heap storage to be reclaimed, but is there any > user-observable state which would cause programs to behave oddly? Just > curious mainly, I don't advocate this as a solution. hs_exit() has three main purposes in GHC: (1) it runs any remaining finalizers (2) it generates the stats output (eg. +RTS -sstderr) (3) it generates the profiling output For (1), we're considering not running finalizers at all at exit time, so that would cease to be a problem. (2) and (3) aren't particularly important - we'll probably do whatever is easiest for the time being, which is to output the stats/profiling the first time and do nothing in subsequent hs_exit()s. An interesting question is whether we can return the RTS to its completely uninitialised state, freeing all the dynamic memory it has accumulated and so on. There are two ways I can see to do this: - Reload the data pages of the executable/library from disk (on demand, of course). - Arrange it so we can do the de-initialisation ourselves. The main thing here is being able to revert all the CAFs that have been evaluated - we already have some of the machinery to do this. I don't think we'll tackle this in the short term, but it would be a nice feature to have. Cheers, Simon

1 0

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 27 Jan '03

27 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 24 Jan '03

24 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