ghc rts selection and third party libraries

[John Lask]

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.

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.


> On 01/02/2010 05:33, John Lask wrote:
> 
>> I hope someone can provide some guidance on how I can solve a certain
>> problem.
>>
>> I have a library that taps into the ghc c rts: specifically when the rts
>> is single threaded I am pumping events in via: stg_pending_events, when
>> the threaded rts is used I use sendIOManagerEvent.
> 
> These are RTS internal APIs, and could change under your feet.  What is 
> it you're trying to do exactly?
> 
>> i.e. I have two versions of the library with the same api. The problem
>> with this is that either library is only good for one context: either
>> threaded rts or not, and the user needs to select the appropriate
>> library to use depending on the use context.
>>
>> What I want to be able to do is to have ghc automatically select the
>> compiled library version to link in depending on the which rts option is
>> selected: "-thread" or not
> 
> Library code is generally supposed to be independent of -threaded; 
> sometimes we do this by checking at runtime using 
> rtsSupportsBoundThreads().
> 
> Cheers,
>     Simon
> 
>