Way to expose BLACKHOLES through an API?

[Jean-Marie Gaillourdet]

Hi,


On 16.11.2011, at 10:43, Duncan Coutts wrote:

> On Tue, 2011-11-08 at 15:43 +0000, Simon Marlow wrote:
> 
>> Hmm, but there is something you could do.  Suppose a thread could be in 
>> a mode in which instead of blocking on a BLACKHOLE it would just throw 
>> an asynchronous exception WouldBlock.  Any computation in progress would 
>> be safely abandoned via the usual asynchronous exception mechanism, and 
>> you could catch the exception to implement your evaluateNonBlocking 
>> operation.
>> 
>> I'm not sure this would actually be useful in practice, but it's 
>> certainly doable.
> 
> The linux kernel folks have been discussing a similar idea on and off
> for the last few years. The idea is to "return" in another thread if the
> initial system call blocks.
> 
> Perhaps there's an equivalent here. We have an evaluateThingy function
> and when the scheduler notices that thread is going to block for some
> reason (either any reason or some specific reason) we return from
> evaluateThingy with some info about the blocked thread.
> 
> The thing that the kernel folks could never decide on was to do with
> thread identity: if it was the original thread that blocked and we
> return in a new thread, or if the original thread returns and a clone is
> the one that blocks.


The difference between the requirements of the Linux kernel folks and the OP is that in the Linux kernel the evaluation has to continue, while in the Haskell case we know that the BLACKHOLE is already evaluated by someone else. I am obviously no expert on the GHC internals, but that is what I understood by reading the papers about the runtime system. So, in GHC I'd say it would make sense to stay in the original thread and throw the exception as Simon Marlow said. 

Just my 2 eurocents.

Cheers, 
 Jean