ghc rts selection and third party libraries

[Simon Marlow]

On 01/02/10 13:36, John Lask wrote:
> I understand these are internals of ghc and subject to change. The
> reason for their use: to support asynchronous interrupts safe with
> respect to the Haskell code that is being interrupted. To my knowledge
> (please correct me if I am wrong) there is no way to do this other than
> the following alternatives and the already mentioned functions.
>
> As an example, suppose I want to provide a call back to a win32 OS hook
> which takes a c-call-back routine. My understanding is that I cannot use
> a wrapped Haskell call-back routine as there are no guarantees what
> state the Haskell rts will be in when the routine is called.

It's not clear to me that this wouldn't work.

I believe it would be perfectly safe for the Win32 console handler 
callback to invoke Haskell functions, because the handler is executed in 
a separate thread, unlike Unix signals which happen in the context of 
one of the existing threads (which is why you can't use any inter-thread 
communication or synchronisation in a Unix signal handler).

> At least initially I have used the above mentioned functions to support
> win32 signal handling, as the ghc rts just catches (and dispatches)
> console events, which do not encompass all the (rather limited) c-rts
> signals.
>
> The obvious solution is to provide a c call-back routine, use an WIN32
> event object, use a Haskell bound thread to wait on that event.
>
> another alternative would be to poll.
>
> The first alternative requires threaded rts which for various reasons I
> don't wish to use under all circumstances, the other alternative is
> inefficient or unresponsive.
>
> Discussion of either of these alternatives distract from the question
> "shouldn't there be a method for asynchronous call-back that is safe
> with respect to the Haskell rts state"?
>
> But there already exists such a method, that of the backdoor already
> mentioned, really, all that is required is for this to become more
> formalised and a single api adopted that is usable from c and consistent
> across threaded and un-threaded rts, but in the mean time the existing
> structure is quite usable for this purpose aside from the cumbersome
> libraries issue.
>
> And the reason for this libraries issue is that the methods exposed by
> the ghc-runtime to collect and post events into the ghc runtime system
> differ between the threaded and non-threaded runtimes, which is why
> short of changing ghc rts myself I can't avoid it (or adopting either of
> the above alternatives)
>
> As the facility (to capture arbitrary asynchronous interrupts) is
> generally useful I believe it to be advantageous to address it rather
> than side-stepping it.

You might want to look at the work that Bryan O'Sullivan and Johan 
Tibell are doing on a new IO manager:

http://github.com/bos/event/

There's no Win32 support yet, but it's designed to allow multiple backends.

Cheers,
	Simon