October 2002 - FFI - Haskell.org

RE: The Death of Finalizers
by Simon Marlow 22 Oct '02

22 Oct '02

> | In the meantime, I'm glad we have got a new function > | atomicModifyIORef > | which I for one will use, when it gets into GHC's regular release. > > Just before this gets out of the door... any chance of calling it > > modifyIORef > > and documenting that it's atomic? Sometimes names can get too long! > > Not a big deal though. It has a different type: atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b modifyIORef :: IORef a -> (a -> a) -> IO () we could either 1. specify that modifyIORef is also atomic. That is useful, because using an atomic version of modifyIORef would be faster than using atomicModifyIORef if you don't need a return value. However, the atomic version of modifyIORef would be slower than the non-atomic version. 2. add atomicModifyIORef_, with the same signature as modifyIORef. I don't really have strong feelings either way, but I think I'd be slightly inclined towards (2) if anything. Cheers, Simon

2 1

RE: Finalizers: conclusion?
by Simon Marlow 22 Oct '02

22 Oct '02

> I also need the touchForeignPtr trick in much of my code. we need to > come up with a replacement if we dont have haskell > finalizers. here are my canidate suggestions: > > * add a subset of Weak pointers (or some subset of their > functionality) > to the FFI spec. just get rid of the finalizer capability > (for obvious > reasons) and the Weak pointers work just as well, and it > might have uses > elsewhere? > > - or - > > * add addForeignDependency :: ForeignPtr a -> ForeignPtr b -> IO () > (which on ghc is trivially implemented as > 'addForeignDependency a b = mkWeak a b Nothing >> return ()') I'm not sure this does what you want. It prevents b's finalizer from being started before a's, but there's nothing that makes them actually run in the desired order. The two finalizers can also be started at the same time, if both a and b are found to be unreachable in a given GC. It *may* be possible to change the semantics of Weak pointers in GHC so that a finalizer is considered a strong root, with the finalizer being passed the key as an argument when it runs. I haven't fully thought through the consequences of this though. In any case, doing it this way isn't ideal either, because it would take multiple full GCs to work out all the dependencies. Maybe you want to synchronise between finalizers using MVars, but of course that only works on GHC, and it might not always be convenient. eg. m <- newEmptyMVar addForeignPtrFinalizer a (putMVar m ()) b <- newForeignPtr p (takeMVar m >> ...) enforces a strict ordering between 'a' and 'b'. A simpler way in some cases is to use addForeignPtrFinalizer directly. If you know that you're creating an object 'a' which should be finalized after some other object 'b', then instead of placing a finalizer on object 'a', place it on object 'b' using addForeignPtrFinalizer. We're going to guarantee ordering between finalizers registered using addForeignPtrFinalizer. This doesn't work if 'a' is possibly referenced from elsewhere, of course. Cheers, Simon

1 0

RE: The Revenge of Finalizers
by Simon Marlow 22 Oct '02

22 Oct '02

> SimonM: > > I can get it to fail another way too: > > > main = do > > p <- mallocBytes 64 > > newForeignPtr p (print x) > > print x > > where > > x = sum [1..10000] Alastair: > The problem is probably this shared mutable variable used behind the > scenes in the implementation of the numeric show code > (hugs98/src/printer.c) > > static Cell out; /* GC'd var used by printer code */ > > [It's also used if you use the -u flag to use Hugs' builtin printer > instead of the Show function - but I don't think anyone does that > anymore and we could probably kill that code without anyone noticing > (???). (Unless, does Hood or some such use it?)] > > > I think all the functions affected return void so it'd be easy to > replace the global variable with a local which is threaded through > that set of functions. My impression is that the problem is more fundamental: the thunk for x is under evaluation when the finalizer begins to run, so it already has a bunch of stuff on the stack. The finalizer starts to run, and demands the value of x - probably we shouldn't get a crash, but a blackhole instead. Fixing it so that the evaluation of x is actually continued is what we want, but I can't see an easy way to do that. I suppose you could suspend either the finalizer or the main thread using the trick of saving its stack on the heap - is this implemented in Hugs? The only other solution I can think of is to delay finalizers until we get back up to the IO monad. Usual disclaimers apply: I have very little idea how the Hugs backend works, so there might be another way around this. Cheers, Simon

4 6

The Death of Finalizers
by George Russell 22 Oct '02

22 Oct '02

Simon Marlow wrote > 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 :-) [snip] How sad. It's an unfortunate hole in the specification and I hope someone will come up with a way of fixing it someday. In the meantime, I'm glad we have got a new function atomicModifyIORef which I for one will use, when it gets into GHC's regular release. It's really nice that we can use laziness to safely update a mutable value without blocking. Another nail in the coffin for Standard ML. I think the addForeignFinalizer function or whatever it is should nevertheless be renamed to addUnsafeForeignFinalizer (and likewise for newForeignObject). There seems no more justification for labelling such foreign finalizers as "safe" than for labelling unsafe foreign function calls as "safe". Also I suppose Alastair's hs_freeStablePtr function which allows you to do it from C, or whatever, will have to be added. I hope Alastair will forgive me for engaging him in such a lengthy argument, when he turns out to have been right all along.

2 1

header files
by Ross Paterson 21 Oct '02

21 Oct '02

In 4.1.1, we have impent -> " [static] [fname] [&] [cid] " so we can specify at most one header file. How about changing that to impent -> " [static] {fname} [&] [cid] " so we can have any number? I know this isn't essential (because I can create a header file containing #include's) but it would be convenient.

2 1

RE: The Revenge of Finalizers
by Simon Marlow 19 Oct '02

19 Oct '02

> > probably we shouldn't get a crash, but a blackhole instead. > > Even a blackhole is wrong. There's no cycle so it ought to evaluate > successfully. I didn't mean to suggest that a blackhole is correct, sorry for the confusion. No, obviously the code should just work. > > Fixing it so that the evaluation of x is actually continued is what > > we want, but I can't see an easy way to do that. > > I think GHC does the right thing (semantically) here. From memory, > GHC works like this: > > on entering thunk: turn it from a thunk into a blocking queue > (optimization: delay the transformation until context switch time) > > on entering a blocking queue: > if cyclic structure (i.e., already under evaluation by > same thread), > report blackhole. > otherwise, put this thread to sleep on the blocking queue. Delete the sentence "if cyclic structure..." and that's correct. If a thread goes to sleep on its own blocking queue, then it just deadlocks, and at some point later it will get a NonTermination exception when the RTS realises what it has done. > Based on this, what does GHC do here when a finalizer tries to > evaluate a thunk already being evaluated? The finalizer is put to > sleep until the main thread finishes evaluation of the thunk. Yup. > And what does GHC do if a call to unsafePerformIO hits a thunk already > under evaluation by the same thread? This is a blackhole (i.e., > deadlock). The thread throws the blackhole exception. Yup. > I think Hugs should report a blackhole in the unsafePerformIO case > (I believe it does already). Unless you try to exit and re-enter the RTS inside unsafePerformIO... (admittedly not very likely, but I bet you could make it fall over this way). > Hugs (and NHC, I believe) have no way to block finalizers once they > start executing. > > I think our only choice is to turn off blackholing, allow the shared > term to be evaluated twice over and hope that the two updates to the > thunk (one by finalizer and then one by the main thread) don't do any > harm. I don't know if this would work. Even if it does, it's not too > palatable because of the loss of sharing and the space leaks (that > blackholing normally fixes). Yes, I don't think this is a good solution. > > I suppose you could suspend either the finalizer or the main thread > > using the trick of saving its stack on the heap - is this > > implemented in Hugs? > > No - it is an STG-specific trick. Hugs is based on the G-machine. > > In Hugs, the state of a pure evaluation is stored on the C stack and > in the heap. We could try longjmp-ing out of the finalizer and hope > that the heap has a full and consistent record of the state but I'm > not overly confident that this would work. (Hmmm, longjmp-ing out is > what exception handlers do and we believe that those work....) > > > The only other solution I can think of is to delay finalizers until > > we get back up to the IO monad. > > and not inside an unsafePerformIO call. right. Cheers, Simon

1 0

RE: The Revenge of Finalizers
by Simon Marlow 18 Oct '02

18 Oct '02

> There's another problem with Simon's patch I haven't been able to pin > down: if you run the example, interrupt it at the right point and type > another expression, the finalizers run, but the expression is lost. I can get it to fail another way too: main = do p <- mallocBytes 64 newForeignPtr p (print x) print x where x = sum [1..10000] Can't believe I didn't realise this kind of thing might be a problem before... guess I was too fixated on the other issues. Anyway, it really needs someone who is familiar with the Hugs backend to comment on whether either of these problems are fixable or not. This one I think you could trigger by using the unsafePerformIO->C->Haskell sequence too. Cheers, Simon

3 2

Erotik �r�n ve video cd ler
by Erotik Market 18 Oct '02

18 Oct '02

Turkiye cag Atliyor..... Tabulari Yikiyoruz ...... Birbirinden ilginc 100 lerce Video CD Film, Her Zevke Uygun Aradiginiz Her cesit Anal, Oral, Vajinal, Fethis, Lezbiyen, Trans, cift cinsiyetli, Zencili, Aile ici, Hayvanli, Vb....Bir cok cesit http://www.erotikgece.com.tr.tc/ http://www.sexshoplayla.com.tr.tc/ 1. sisme Bebek cesitleri..... Birbirinden harika 3 islevli anal, oral, vajinal bebekler, Esmer, Sarisin, Kumral Size hicbir zaman hayir demeyecekler... 2. Vibrator cesitleri........ istediginiz boy ve ebatlarda pilli titresimli Gercegini hicbir zaman aratmayacak... 3. Realistik Penis cesitleri. Super realistik ten hassasiyetinde, gercek bir penisten beklediginiz herseyi size verir... 4. Suni Vajina cesitleri..... Gercek bir vajinadan beklediginizden fazlasini alacaksiniz, tahmin edemeyeceginiz ozelliklere sahip... 5. Penis Buyutuculer......... Sakin Komplekse girmeyin duzenli kullanimlarda 2cm. ile 4cm. arasinda uzunluk saglayabilirsiniz... 6. Uyandiricilar............. Cinsel guc ve istek artirici, Uyarilmayi ve ereksiyonu kolaylastirici damlalar ve hap cesitleri... 7. Krem cesitleri............ Anal ve Vajinal Kayganlastirici, Geciktirici krem cesitleri... 8. Video CD. cesitleri ........... http://www.erotikgece.com.tr.tc/ .. http://www.sexshoplayla.com.tr.tc/ ................................... Ve Son Olarak cok Yakinda Sadece Dogal Olan Naturel urun cesitleri ile Karsinizda olacagiz... Bekleyin... Yapmaniz Gereken Tek sey Arkaniza Yaslanin Ve Tiklayin http://www.erotikgece.com.tr.tc/ http://www.sexshoplayla.com.tr.tc/

1 0

Re: C Struct Field Access
by Ashley Yakeley 18 Oct '02

18 Oct '02

At 2002-10-17 17:55, Manuel M T Chakravarty wrote: >Why do all the work yourself when a tool can do it for you? A tool has its own overhead. For instance, I'd have to make sure c2hs is installed on all platforms I build on. If I start doing a lot more FFI, I might switch over. But right now it's just this one data-structure that's tricky... -- Ashley Yakeley, Seattle WA

1 0

C Struct Field Access
by Ashley Yakeley 18 Oct '02

18 Oct '02

What's the best strategy for accessing fields in someone else's C struct? Should I write my own glue file with accessor functions? Or should I make a Storable instance for the struct? -- Ashley Yakeley, Seattle WA

2 1