<div dir="auto"><div>I did actually construct a workaround where I compute in a separate (forked, via System.Posix) <i>process </i>to time it out, then recomputed in the main process to get the value. It's got a significant overhead but I'm not sure yet if that is a real issue.</div><div dir="auto"><br></div><div dir="auto">Using just a separate rts thread is how the standard timeout works; if you mean that those guys use a separate OS thread that gets scheduled outside the rts, that would be perfect. I'm just faking that with the fork.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Thu, Nov 29, 2018, 02:16 Erik Hesselink <<a href="mailto:hesselink@gmail.com">hesselink@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hi Ryan,</div><div><br></div><div>I'm not quite sure of your use case, but lambdabot/mueval do something like this I think. From a brief look at the source [1] it seems they compute in a separate thread, then in another thread, wait until the timeout then kill the computation thread. Would something like that work for you?</div><div><br></div><div>Erik<br></div><div><br></div><div>[1] <a href="https://github.com/gwern/mueval/blob/09b6a7aa5a25c4115442ea2e6ae0c2db557007f8/Mueval/Parallel.hs" target="_blank" rel="noreferrer">https://github.com/gwern/mueval/blob/09b6a7aa5a25c4115442ea2e6ae0c2db557007f8/Mueval/Parallel.hs</a><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 29 Nov 2018 at 03:41, Ryan Reich <<a href="mailto:ryan.reich@gmail.com" target="_blank" rel="noreferrer">ryan.reich@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I expected something like that. I'm all the way back in ghc-8.2.2, but I think what this really shows is that the flag is unreliable and version-dependent. Unfortunately there doesn't seem to be a precise specification of where yield points should appear, and therefore, where they might be not-omitted.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 28, 2018, 17:10 Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org" target="_blank" rel="noreferrer">ietf-dane@dukhovni.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Nov 28, 2018 at 09:39:01AM -0800, Ryan Reich wrote:<br>
<br>
> Thanks for the suggestion, which Arjen made also.  Unfortunately, it does<br>
> not appear to help.  See this simple program:<br>
> <br>
> -- Loop.hs<br>
> import Control.Exception<br>
> import System.Timeout<br>
> <br>
> main :: IO (Maybe Integer)<br>
> main = timeout 100000 $ evaluate $ last $ repeat 0<br>
> -- end<br>
> <br>
> With either GHC invocation "stack exec ghc Loop[ -- -fno-omit-yields]",<br>
> running ./Loop fails to terminate (it should do so in 0.1s).<br>
> <br>
> Based only on the very terse description of that flag in the User's Guide,<br>
> and its name, I think the problem is simply that GHC doesn't normally<br>
> *generate* yields in that loop, so there's nothing not to omit.<br>
<br>
It times out for me with GHC 8.4.4 on FreeBSD 11.2, and "ghc -O -fno-omit-yields"<br>
and does  not time out with "ghc -O":<br>
<br>
    $ cat /tmp/foo.hs<br>
    import Control.Exception<br>
    import System.Timeout<br>
<br>
    main :: IO (Maybe Integer)<br>
    main = timeout 1000000 $ evaluate $ last $ repeat 0<br>
<br>
    $ ghc -O -fno-omit-yields /tmp/foo.hs<br>
    [1 of 1] Compiling Main             ( /tmp/foo.hs, /tmp/foo.o ) [Optimisation flags changed]<br>
    Linking /tmp/foo ...<br>
<br>
    $ time /tmp/foo<br>
<br>
    real    0m1.033s<br>
    user    0m1.025s<br>
    sys     0m0.008s<br>
<br>
    $ rm /tmp/foo<br>
    $ ghc -O /tmp/foo.hs<br>
    [1 of 1] Compiling Main             ( /tmp/foo.hs, /tmp/foo.o ) [Optimisation flags changed]<br>
    Linking /tmp/foo ...<br>
<br>
    $ time /tmp/foo<br>
    ^C^C<br>
<br>
    real    0m5.864s<br>
    user    0m5.857s<br>
    sys     0m0.000s<br>
<br>
On MacOS X with GHC 7.10.3, it does not time out either way.  Perhaps<br>
some versions of GHC don't make the timeout possible.<br>
<br>
-- <br>
        Viktor.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>
</blockquote></div></div></div>