Simon Peyton-Jones wrote:
> Yes, we do this a lot. It's such a useful thing that I wonder
> whether we should support it more directly, somehow.
That eases my mind. :-) I feared that I'm the only one doing this
kind of hackery...
> As it stands, its vulnerable to 'blockingSem' getting inlined at its
> usage sites, which would be a total disaster. That's what you get
> with unsafePerformIO; we've even added a {-# NOINLINE blockingSem #-}
> pragma for exactly this reason. (Doubtless undocumented.)
That's a surprise! (Well at least if -ddump-simpl is not one of your
favourite options.) I'll better have a look at my GLUT stuff again...
:-}
> I'd like to have a better design.
Agreed. And while we're at it: Something like
updateIORef :: IORef a -> (a -> a) -> IO ()
would be nice in the standard libs, even if it's a two-liner.
> > But I've another callback-related question: How should adjustor thunks
> > (aka Haskell callbacks) be freed? Assume the following scenario:
> >
> > 1. Create a callback via the foreign export ccall mechanism.
> > 2. Register it to the C-API (GTK+, GLUT, etc.)
> > 3. After a while, the callback is called from C-land (following
> > obscure paths through the RTS laid out by Sigbjorn :-)
> > 4. The callback wants to re-register a new callback for the same
> > event.
> > 5. The running "old" callback can still do anything it pleases
> > 6. The callback finishes
>
> Is there a problem here? Presumably you are using foreign
> export dynamic for step (1). To do step (2) you have to make the
> callback into a stable pointer;
Hmmm, currently I'm using the Addr returned from (1) directly for
registration.
> that will keep it alive until the stable pointer is explicitly freed.
> In step (4) you can free the stable pointer to the old callback.
> That doesn't cause the thing to be garbage collected if it's still
> executing; it simply means that the GC knows that there's no *external*
> pointer to it.
Aaaah! *lights going on* But then I suggest that foreign export
dynamic should be changed to return a stable pointer instead of an Addr.
This shouldn't break too much code, because both are CCallable.
> Or have I missed something?
No, I did... :o)
Cheers,
Sven
--
Sven Panne Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED] D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
