[Haskell-cafe] Timing out a pure evaluation of an expression I did not write myself

[Ryan Reich]

I suppose my question concerns the more general question of how to create
OS-managed threads in GHC.  As I understand it, GHC's concurrency model
only exposes its RTS-managed internal threads, which are distributed
somehow to OS threads by the scheduler, and this is the source of my
timeout problem, because the scheduler never runs.  Contrast this with
plain Linux C, where we can do something with pthread_create to call a
function in an OS-managed thread directly.  I would have expected there to
be a corresponding operation in GHC Haskell ("bound threads" seem not to be
it, as they are still scheduled by the RTS) but it does not appear that
there is.  Is this because of the need to keep the runtime unified?
Because it seems strange that we are prevented from operating truly
independent threads.

Ryan

On Sat, Nov 17, 2018 at 3:21 PM Ryan Reich <ryan.reich at gmail.com> wrote:

> I want to time out a pure computation.  My experience, and that described
> in various previous questions here and elsewhere (the best of which is
> https://mail.haskell.org/pipermail/haskell-cafe/2011-February/088820.html),
> is that this doesn't always work: for instance,
>
> >>> timeout 1 $ evaluate $ let x = 0 : x in last x
>
> does not time out because, apparently, the fact that the expression
> evaluates in constant space (i.e. never allocates) means that it never
> yields to the timeout monitor thread that would kill it.
>
> The solution that is described in the other iterations is to embed
> checkpoints in the expression that do allocate, giving the RTS a chance to
> switch contexts.  However, in my application, the expression is /arbitrary/
> and I do not have the freedom to inject alterations into it.  (Don't argue
> this point, please.  The expression is arbitrary.)
>
> How can I time out a tight loop like the above?  Clearly, it can be done,
> because I can, say, alt-tab over to another terminal and kill the process,
> which exploits the operating system's more aggressively pre-emptive
> scheduling.  Is there a solution using bound threads, say 'forkOS' instead
> of 'forkIO' in the implementation of 'timeout'?  Unix signals?  Some
> FFI-based workaround?  Etc.  Keep in mind that notwithstanding that
> comment, I don't actually want to kill the whole process, but just the one
> evaluation.
>
> Thanks in advance,
> Ryan Reich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20181119/e6fc7058/attachment.html>