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

Ryan Reich ryan.reich at gmail.com
Wed Nov 28 17:39:01 UTC 2018


Thanks for the suggestion, which Arjen made also.  Unfortunately, it does
not appear to help.  See this simple program:

-- Loop.hs
import Control.Exception
import System.Timeout

main :: IO (Maybe Integer)
main = timeout 100000 $ evaluate $ last $ repeat 0
-- end

With either GHC invocation "stack exec ghc Loop[ -- -fno-omit-yields]",
running ./Loop fails to terminate (it should do so in 0.1s).

Based only on the very terse description of that flag in the User's Guide,
and its name, I think the problem is simply that GHC doesn't normally
*generate* yields in that loop, so there's nothing not to omit.


On Mon, Nov 26, 2018 at 4:14 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> so one way to handle no allocation things playing nicely with the
> scheduler is to compile haskell code with -fno-omit-yields
>
> this will generate code which has scheduler yields even in loops which
> dont allocate
>
> cheers!
> -Carter
>
> On Mon, Nov 19, 2018 at 3:27 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
> wrote:
>
>> On Mon, Nov 19, 2018 at 11:26:17AM -0800, Ryan Reich wrote:
>>
>> > I suppose my question concerns the more general question of how to
>> create
>> > OS-managed threads in GHC.  [...]
>> > 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.
>>
>> I was just reading:
>>
>>     https://cs.nyu.edu/~mwalfish/classes/14fa/ref/boehm05threads.pdf
>>
>> which may offer some insight.  The runtime needs to be able to
>> provide a consistent memory model to threads.  Just running something
>> in an OS thread that's managed by the RTS could make that difficult,
>> and it is not clear how that cooperates with garbage collection.
>>
>> But to your point, when adding threads to your example, I find that
>> the infinite loop then runs concurrently in all the threads, and
>> the timeout never happens.  While:
>>
>>     Replacing:   let x = 0:x in last x
>>     with:        let ! x = 0 + x in x
>>
>> does make timeout work, so it is not entirely obvious which pure
>> computations can be timed out.
>>
>> --
>>         Viktor.
>> _______________________________________________
>> 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.
>
> _______________________________________________
> 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/20181128/0fc7abb5/attachment.html>


More information about the Haskell-Cafe mailing list