"Manuel M. T. Chakravarty" wrote:
> [...]
> The required synchronization could of course be programmed
> using `Concurrent's semaphores, but with the disadvantage
> that if we want to provide this thread-safety transparently
> for user applications in a library, we have to define a
> "new" IO monad on top of the standard one (to thread the
> reference to the semaphore to all library calls). As a
> consequence, all standard IO operations would have to be
> lifted to the new IO monad.[2] [...]
I'm not sure if this is neccessary, because it is possible to have
global (mutable!) variables via IORefs + unsafePerformIO:
\begin{UseHaskellLikeC}
blockingSem :: IORef QSem
blockingSem = unsafePerformIO (newIORef =<< newQSem 1)
gtkMumbleFooBar :: ... -> IO ()
gtkMumbleFooBar ... = do
...
waitQSem =<< readIORef blockingSem
doObscureGTKStuff
...
\end{UseHaskellLikeC}
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
When should the adjustor thunk for old callback created in step 1 be
freed? After 6., but I can't see how... Note: 4. is definitely too
early, because the old callback is still running and on its termination
control goes back through the adjustor thunk. Probably some weak pointer
trickery can help, but I have no clue how to do it exactly yet.
Note: Complicated as the above scenario seems, it is quite common for
many APIs, e.g. a timer callback often wants to re-register another
timer callback.
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
