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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
