Questions on the RTS C API regarding threads and tasks

[Nicola Gigante]

Ping?

Please tell me if my questions were unclear. 

Thank you,
Nicola

Il giorno 05 nov 2015, alle ore 08:13, Nicola Gigante <nicola.gigante at gmail.com> ha scritto:
> 
>> Il giorno 05 nov 2015, alle ore 05:27, Edward Z. Yang <ezyang at mit.edu> 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?
>>