Questions on the RTS C API regarding threads and tasks
Edward Z. Yang
ezyang at mit.edu
Thu Nov 5 04:27:15 UTC 2015
Excerpts from Nicola Gigante's message of 2015-11-04 11:12:39 -0800:
> I’ve started delving into the ghc runtime API to understand
> if everything we need is exposed to the world or if we
> have to modify the runtime itself (which I would avoid if possible).
I agree with this goal in principle, but:
(1) Depending on what you want to do, it may be quite difficult to
do this, and
(2) The RTS is actually quite hackable (as long as you are not
changing any of the interfaces with generated Haskell code, you
could even build your own RTS and have users link against that.)
Something to keep in mind.
> I have a few questions about the functions that the runtime
> exports to the C world regarding the manipulation of tasks:
>
> - Fundamentally, is there a way for a C function called by a foreign call
> to suspend the haskell thread that called it, to be resumed later
> when appropriate? I see that the runtime has a concept of
> “blocking queue”, but I also see that the functions that work on
> blocking queues are not exported. I can manage a queue of TSOs myself,
> but then I need a way to put in sleep the task indefinitely up to a wake signal.
> In other words, can I sleep and awake haskell threads from a C function
> called by a foreign call?
Not easily. If you make a safe foreign call, the capability is given up
before the C code executes, so you actually lose ownership of the
capability and TSO by the time you're running C code. The only
way to write a foreign call to properly suspend the thread that called
it is a primop function (e.g. stg_putMVar), and the operation is quite
delicate and you will probably want to use some existing (internal)
code in the RTS to do it.
But if you just need to sleep/awake threads, why not just use an MVar?
Edward
More information about the ghc-devs
mailing list