Questions on the RTS C API regarding threads and tasks

[Nicola Gigante]

> Il giorno 12 nov 2015, alle ore 12:24, Simon Marlow <marlowsd at gmail.com> ha scritto:
> 
> When you call a C function from Haskell, the Haskell thread that called it *is* suspended, until the C call returns.  So I'm not sure exactly what it is you want to do - maybe you could describe in more detail?
> 

Yes, the haskell thread is suspended but it will be resumed when the C code returns.
If you see the haskell + C code as a single computation, nothing gets suspended,
you just switch environment and language.

I’m sorry for the vagueness in my question. At the time we had a blind review of 
a paper pending so I couldn’t give more details because some reviewer could be
a member of mailing lists like this.

Now I can explain at a little bit higher level what I was talking about.
There are a few places in the haskell concurrency libraries where
haskell threads gets suspended until something happens.
MVars suspend on reads, STM transactions block after a retry to wait for
the change of some TVar, and so on…
Each case is internally treated explicitly by the runtime. By looking at the
implementation I see that there is a concept of “Blocking Queue”, and
each TSO can be added to one of these queues. Each TSO also has
a why_blocked flag that tells why it is blocked, with all these cases explicitly
enumerated (e.g. BlockedOnCCall and BlockedOnSTM).

We are implementing some kind of concurrency primitive, which is similar in spirit
to the STM but with a number of differences, and we’d need access to
a primitive to block the thread exactly as it happens with the readMVar function
or the retry action of the STM: simply put a thread to sleep until something happens.

We are implementing a concurrency primitive, so everything has to be fast and low-overhead.
As Edward pointed out, it sounds like premature optimization to a priori exclude
the possibility to implement our primitive on top of MVars. For this reason, that
is the way that we are exploring in the last days.

Nevertheless, it does seem strange to us that the GHC runtime doesn’t expose 
some generic way to do something that is needed by so many subsystems.
What do you think about this? Are we missing something?

Thank you for your help,

> Cheers,
> Simon

Greetings,
Nicola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151112/f8b692f8/attachment.html>