<div dir="ltr">Hey Jesper,<div style>thanks for the headsup!</div><div style><br></div><div style>please continue to share you findings on this matter, It sounds like it'll be really useful for folks! </div><div style>
<br></div><div style>-Carter</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 18, 2013 at 9:19 AM, Jesper Särnesjö <span dir="ltr"><<a href="mailto:sarnesjo@gmail.com" target="_blank">sarnesjo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Mar 18, 2013 at 11:27 AM, Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br>
> On Sun, Mar 17, 2013 at 7:58 PM, Jason Dagit <<a href="mailto:dagitj@gmail.com">dagitj@gmail.com</a>> wrote:<br>
>> On Sat, Mar 16, 2013 at 6:53 PM, Jesper Särnesjö <<a href="mailto:sarnesjo@gmail.com">sarnesjo@gmail.com</a> wrote:<br>
>>><br>
>>> To be clear, I think this isn't really an OpenGL problem, but rather<br>
>>> one related to FFI or event handling. If anyone could explain to me,The<br>
>>> release notes for 7.0.1 said this about that flag:<br>
>><br>
>> There is a new -fno-ghci-sandbox flag, which stops GHCi running<br>
>> computations in a separate thread. In particular, this is useful for GLUT on<br>
>> OS X, which only works if being run on the main thread.<br>
><br>
> Worth noting is that Jesper said it *works* in ghci, and fails when<br>
> compiled....<br>
<br>
</div>Interestingly, running the program in GHCi with the -fno-ghci-sandbox<br>
flag, causes it to misbehave in the same way as when compiled:<br>
<br>
$ ghci -fno-ghci-sandbox -lglfw glfw_test.hs<br>
[...]<br>
*Main> main<br>
Apple Software Renderer<br>
<br>
This is starting to smell like a concurrency-related issue, then. I<br>
should note that the GLFW library does use multiple OS threads, and I<br>
know from previous experience that Mac OS X is fussy about GUI actions<br>
being run on the main thread. The curious thing here, of course, is<br>
that the behavior I am seeing is the exact opposite of that mentioned<br>
in the release notes.<br>
<br>
I've found some interesting reading material on how GHC handles the<br>
interaction of concurrency and FFI, in particular the paper "Extending<br>
the Haskell Foreign Function Interface with Concurrency" by Simon<br>
Marlow and Simon Peyton-Jones [1], which even brings up OpenGL as an<br>
example of why a programmer must be able to "specify that a related<br>
group of foreign calls are all made by the same OS thread". I haven't<br>
yet had the time to dig too deep into this, but I have tried a few<br>
things:<br>
<br>
* I've compiled the program with -threaded (as suggested by John<br>
Lato), with the foreign functions marked as safe and unsafe (as<br>
suggested by Carter Schonwald).<br>
* I've checked that the main thread of my Haskell program is bound to<br>
an OS thread [2], which it is when using the threaded runtime. I've<br>
also tried explicitly running the block of foreign calls in a bound<br>
thread [3].<br>
* I've made sure that there is only one GLFW library on my machine for<br>
-lglfw to link with, and that it is the very same library my C program<br>
links with.<br>
<br>
None of the above helped. However, I will keep investigating and see<br>
what I find.<br>
<br>
As I final note, I did learn that the GHC runtime generates SIGVTALRM<br>
signals to cause the scheduler to switch contexts [4][5]. Perhaps this<br>
prevents GLFW from running properly? Looks like I'll need to brush up<br>
on my dtrace.<br>
<div class="im"><br>
--<br>
Jesper Särnesjö<br>
<a href="http://jesper.sarnesjo.org/" target="_blank">http://jesper.sarnesjo.org/</a><br>
<br>
</div>[1] <a href="http://community.haskell.org/~simonmar/papers/conc-ffi.pdf" target="_blank">http://community.haskell.org/~simonmar/papers/conc-ffi.pdf</a><br>
[2] <a href="http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:isCurrentThreadBound" target="_blank">http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:isCurrentThreadBound</a><br>
[3] <a href="http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:runInBoundThread" target="_blank">http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:runInBoundThread</a><br>
[4] <a href="http://joeyh.name/blog/entry/ghc_threaded_runtime_gotchas/" target="_blank">http://joeyh.name/blog/entry/ghc_threaded_runtime_gotchas/</a><br>
[5] <a href="http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals#RTSAlarmSignalsandForeignLibraries" target="_blank">http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals#RTSAlarmSignalsandForeignLibraries</a><br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>