Re: Running a final finaliser
On Monday 05 Jan 2004 3:14 pm, Simon Marlow wrote: The other complication I can see is that ForeignPtr finalisers can't be Haskell. So I have to call the Haskell finalisation from C. Is that safe? I'm afraid I still don't fully understand why Haskell finalisers are unsafe or why (if) calling Haskell from a C finaliser (which then called C land again) would be any safer. If you don't mind your code being non-portable, then Foreign.Concurrent provides Haskell finalisers. Oh yes, so it does :-) I'd just been looking at the FFI documentation (only). Thanks for pointing that out. This support will be available only on Haskell implementations which implement pre-emptive concurrency (i.e. just GHC for now). OK, I think understand now thanks to Alistair Reids explanation. I had been trying to keep my code portable (it's a library binding I hope to make available to Haskell folk sometime soon). But this seems to be quite difficult. AFAICS the situation is that the only really portable solution to this problem is for the reference counting thing (or doubly linked lists or whatever) to be done in C (which I guess is what everybody's been saying all along :-). Regards -- Adrian Hey ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running a final finaliser
Hello, Thanks for that explanation, I see the problem now. Though to be honest, I'm not convinced that the situation for Haskell implementations which don't implement pre-emptive concurrency need be as bad as you suggest. But that's probably presumptious of me seeing as I know little about the implementations of either Hugs or nhc (or ghc for that matter:-) I can see there is a potential problem with single threaded programs which may never call yield, though even in this situation it I would think it would be relatively straight forward to have an implicit yield to finalisers at appropriate points (no partially reduced thunks in the heap). But then again, I guess the logic is that since foreign object finalisers will usually be foreign functions which don't re-enter Haskell it's probably not worth the effort. The other thing that strikes me about this is don't we also have the same potential problem with weak pointer finalisers? Can they be supported in Haskell without pre-emptive concurrency? Regards -- Adrian Hey On Monday 05 Jan 2004 4:39 pm, Alastair Reid wrote: I'm afraid I still don't fully understand why Haskell finalisers are unsafe or why (if) calling Haskell from a C finaliser (which then called C land again) would be any safer. The FFI standard doesn't say that calling C finalizers is unsafe (which would imply that the finalizers potentially do something naughty). Rather, the standard says that finalizers are called in a restricted context in which they are not allowed to call back into Haskell. The reason that finalizers must be written in C and cannot call into Haskell is that it requires pretty much all the machinery needed to implement preemptive concurrency (multiple C stacks, context switches, etc.) which was felt to be an excessively high burden on a Haskell implementation just to let you call C functions. (Of course, GHC already has this machinery which is why they provide enhanced functionality.) Why does it require most of the machinery of preemptive concurrency? Suppose that a finalizer requires the value of something that is currently being evaluated by the main thread. (This is very common and pretty much impossible to reason about in Haskell. For example, it could be a dictionary object or the thunk '(==) dict_Int'.) The correct thing to do if this happens is to block the finalizer, run the main thread until the shared thunk is updated with a value, and then restart the finalizer. To block a thread in this way, we have to switch C stacks, perform a context switch, etc. QED. -- Alastair Reidhaskell-consulting.com ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fail: unknown exception
Simon Marlow wrote: This has to be one of the most irritating ways a program can fall over. Can't the Haskell RTS try just a /little/ harder to help the poor programmer? For example by saying what sort of exception it is, and (if it's a dynamic exception) what type it has? An unknown exception is a dynamic exception. GHC just uses the ordinary instance of Show on Exception to print out the value of an exception, and it so happens that all it prints out for a dynamic exception is unknown exception. Arguably the show instance should print out the type too. It could; I just looked into it and unfortunately there's an annoying module loop in the libraries which means doing this would entail some restructuring. Why can't GHCi just print out the type itself? Because it has to be done in the context of the interpreted program, which means GHCi would have to compile a little snippet of code to show the exception. Annoying, but doable. Alternative suggestion: could the RTS provide a global variable containing a value of type Maybe (Exception - Maybe String)? If set, this would be called whenever the RTS attempted to display an uncaught exception, and the String returned if any displayed. I know this is really an awful hack but (a) it's what I want; (b) you didn't expect exceptions to be nice did you?; (c) wouldn't it avoid the above restructuring and GHCi hackery? We could argue the details of the value. For example storing a list of functions with tags [(String,Exception - Maybe String)] to be tried in order would allow the user to selectively delete particular descriptive functions. This hardly seems necessary, but in any case it might be better to restrict the visible user interface to addGlobalExceptionDescriber :: (Exception - Maybe String) - IO () to allow for future developments ... ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Compiling HOpenGL Examples with GHC 6.2 Mac OS
Hi, as far as I understand now, for my compiliing problem (see last past with same subject) I must do ghc -package OpenGL -package GLUT --make Cube.hs and in the code doing import OpenGL import GLUT Right so far ? But it seems that the package description in the GHC 6.2 distribution is not right for this packages (OpenGL and GLUT), for both the directory $(InstallDir)/Graphics/Rendering and $(InstallDir)/Graphics/UI is used .??? Greetings Hans ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
