Re: Questions on the RTS C API regarding threads and tasks

Ping? Please tell me if my questions were unclear. Thank you, Nicola Il giorno 05 nov 2015, alle ore 08:13, Nicola Gigante ha scritto:

...

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

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?

...