Il giorno 05 nov 2015, alle ore 05:27, Edward Z. Yang ha scritto:

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.

Edward, thanks for the quick reply! Yes, I see that the source code is clear and well documented! :) However, this project is something we would eventually want to publish on hackage, not something of internal use. This means we'd have to contribute the runtime changes upstream, which would be cool but I assumed GHC as a project doesn't accept every experimental new feature that come across, and we don't have the energy to guarantee maintenance of this eventual contribution. An external solution would be better.

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?

We don't have measurements, but we ruled out this possibility for performance reasons. Our idea is to make a thin Haskell wrapper around a tiny bit of highly optimized C code. What's the performance of locking on MVars? While we are at it: are primops callable directly from C? I suppose calling conventions are different. A question comes to mind: you mentioned "safe" calls. Are unsafe calls different regarding the detaching of the capability? Also: would a patch to make this possible be accepted? In particular: - add a way to make a "ultraunsafe" foreign call that do not loose the ownership of the calling thread. - add a BlockedOnExplicitSleep flag for tso->why_blocked (And in turn this means managing a different blocking queue, right?) - export something to reliably put in sleep and resume threads in this way. Is this feasible? Would it be a good idea?

Edward

Thank you again, Greetings, Nicola