<div dir="ltr">Thanks Zubin! That looks very much on the mark. We might not need to change GHC after all if we can avoid calling the R runtime from Template Haskell [4].<div><br></div><div>[4] <a href="https://github.com/tweag/HaskellR/issues/369">https://github.com/tweag/HaskellR/issues/369</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 16, 2021 at 3:11 PM Zubin Duggal <<a href="mailto:zubin@well-typed.com">zubin@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A patch to run Template Haskell code in a forked thread was included in<br>
ghc-8.10.6: <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5042" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5042</a><br>
<br>
This was chosen as the only robust way to avoid reporting any<br>
asynchronous exceptions thrown to the compilation process during TH<br>
evaluation as a user error in TH code. If you cancel a compile by<br>
throwing the compilation thread an exception, we don't want to catch<br>
that error in GHC and report it as if the TH code had a regular<br>
exception. By running the TH code in a forked thread and not sharing<br>
the ThreadId, we ensure that any exception caught during the evaluation<br>
of TH code either originated from the code itself or was thrown by the<br>
RTS directly to the TH code (BlockedIndefinetelyOnMVar,... etc.).<br>
<br>
There may be alternative solutions to this or ways to make this<br>
behaviour configurable. I would urge you to open an ticket on the GHC<br>
tracker detailing your use case.<br>
<br>
On 21/11/16 11:26, Domínguez, Facundo wrote:<br>
>Dear devs,<br>
><br>
>I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving<br>
>differently than previous compilers when running Template Haskell code.<br>
><br>
>When upgrading HaskellR to use a newer ghc I found that it would work fine<br>
>with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R<br>
>runtime in particular, is sensitive to local state in the threads that are<br>
>used to execute the runtime. HaskellR is arranging to run the R runtime<br>
>when running TemplateHaskell splices, and this stopped working in MacOS<br>
>with ghc-8.10.6.<br>
><br>
>The error I got is not new. It comes from R and we would get it in ghci if<br>
>we try to use HaskellR without passing the command line flag<br>
>-fno-ghci-sandbox. But this is the first time we get the error when using<br>
>TemplateHaskell.<br>
><br>
>Does anyone know if there have been changes to the threads in which the TH<br>
>splices are run? And were there any changes specific to TH in MacOS?<br>
><br>
>Thanks in advance,<br>
>Facundo<br>
><br>
>[1] <a href="https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170" rel="noreferrer" target="_blank">https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170</a><br>
<br>
>_______________________________________________<br>
>ghc-devs mailing list<br>
><a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br>
</blockquote></div>