Way to expose BLACKHOLES through an API?

[Ryan Newton]

Jan voted for the explicit "lockAndBlackhole" version as safer.

I realize that for the Bytestring example all you would want to "gently"
consume what is already available is WHNF detection alone.  In that
scenario you don't want to evaluate anything, just consume what is already
evaluated.

I would propose that when you do want to explicitly and actively blackhole
something that that call be non-blocking (i.e. if someone else has already
blackhole'd you don't wait).  So the state machine would go:

tryAcquire x =
 case unsafeRTStatus x of
   Blackhole   -> return Nothing
   Unevaluated -> do b <- tryBlackhole x
                     if b
                      then return (Just x)
                      else return Nothing
   Evaluated   -> return (Just x)




>> It would simply return Nothing if the value is BLACKHOLE'd.  Of course
>> it may be helpful to also distinguish the evaluated and unevaluated
>> states.  Further, the above simple version allows data-races (it may
>> become blackhole'd right after we evaluate).  An extreme version would
>> actively blackhole it to "lock" the thunk... but maybe that's overkill
>> and there are some other good ideas out there.
>
> I'd submit that your latter suggestion is far safer: return Nothing
> unless we successfully blackhole the thunk or find that it's already
> been evaluated.  We actually *know* the blocking behavior we'll get,
> and it's behavior we can't easily obtain through any other mechanism
> (eg we'd have to add multiple unsafe indirections through mutable
> cells into the lazy bytestring implementation to obtain the same
> behavior in any other way, and essentially write out the laziness
> longhand losing the benefits of indirection removal and so forth).


>> A mechanism like the proposed should, for example, allow us to consume
>> just as much of a lazy Bytestring as has already been computed by a
>> producer, WITHOUT blocking and waiting on that producer thread, or
>> migrating the producer computation over to our own thread (blowing its
>> cache).
>
> For that you probably want WHNF-or-not detection as well (at least if
> you want to schedule streaming of computation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20111107/76e74152/attachment.htm>