Feasibility of native RTS support for continuations?

[Simon Marlow]

On Mon, 10 Feb 2020 at 08:17, Simon Marlow <marlowsd at gmail.com> wrote:

> On Mon, 10 Feb 2020 at 08:10, Alexis King <lexi.lambda at gmail.com> wrote:
>
>> On Feb 6, 2020, at 02:28, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>> The issue here is that raiseAsync is destructive - it *moves* the stack
>> to the heap, rather than copying it. So if you want to continue execution
>> where you left off, for shift#, you would have to copy it back onto the
>> stack again. That's the point I was trying to highlight here.
>>
>>
>> Ah, yes, I see what you mean! It happens that for my use case I actually
>> do want to unwind the stack when I capture a continuation, so that isn’t a
>> problem for me.
>>
>> Yes, these are all the things that make raiseAsync tricky! You can either
>> copy what raiseAsync does (but be warned, it has taken a lot of iteration
>> to get right) or try to use raiseAsync and/or modify it to do what you want.
>>
>>
>> My point was more that I’m unsure that shift# *should* handle most of
>> those cases. For raiseAsync, it makes sense, since asynchronous interrupts
>> can, by their nature, occur at any time, even during pure code. But my
>> shift# operation lives in IO, and the intent is to only capture up to a
>> reset# in the same state thread.
>>
>> My justification for this is that if you could use shift# in pure code,
>> it would be ill-defined what you’d even be capturing. Suppose you return a
>> thunk containing a call to shift#. When the thunk is evaluated, you capture
>> up to the nearest reset#… but who knows what that is now? This opens you up
>> to all sorts of general badness.
>>
>> Therefore, I don’t think there should ever be an UPDATE_FRAME in the
>> captured continuation—if there is, it’s probably a bug. So unless someone
>> can think of any valid use cases, I’ll make that more explicit by modifying
>> the continuation-capturing code to add some assertions that those frames
>> never appear in the captured stack.
>>
>
> Let me just say "unsafePerformIO" :)  You probably want to at least ensure
> that things don't crash in that case, even if you can't give a sensible
> semantics to what actually happens. We have a similar situation with
> unsafeIOToST - we can't tell you exactly what it does in general, except
> that it doesn't crash (I hope!).
>

Typo - I meant unsafeIOToSTM here.


>
> Cheers
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200210/578f0318/attachment.html>