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

Daniel Díaz Casanueva dhelta.diaz at gmail.com
Sun Nov 18 00:55:56 UTC 2018

Actually, after reading the question again, it seems like my response
wasn't quite right. You are not actually building the list. In that case, I
am as confused as you. :)


Am So., 18. Nov. 2018 um 01:51 Uhr schrieb Daniel Díaz Casanueva <
dhelta.diaz at gmail.com>:

> Hello Ryan.
> Try evaluating the expression to normal form instead of weak head normal
> form in your expression. So:
> >>> timeout 1 $ evaluate $ force $ let x = 0 : x in last x
> The function `force` comes from the deepseq package. You can read the docs
> here:
> http://hackage.haskell.org/package/deepseq-
> I hope that helps.
> Best regards,
> Daniel
> Am So., 18. Nov. 2018 um 00:22 Uhr schrieb Ryan Reich <
> ryan.reich at gmail.com>:
>> 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
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20181118/cc14c57d/attachment.html>

More information about the Haskell-Cafe mailing list