Questions on the RTS C API regarding threads and tasks

[Nicola Gigante]

Il giorno 05 nov 2015, alle ore 05:27, Edward Z. Yang <ezyang at mit.edu> 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