Re: Odd FFI behavior
Donn, Thanks, this solved the problem. I would like to know more about what the signals are doing, and what am I giving up by disabling them? My hope is I can then go back to the dll expert and ask why this is causing their library a problem and try to see if they can solve the problem from their end, etc. Mike On Aug 12, 2014, at 11:04 PM, Donn Cave d...@avvanta.com wrote: ... Because the failures are not general in that they target one particular value, and seem to be affected by time, it makes me wonder if there is some subtle Haskell run time issue. Like, could the garbage collector be interacting with things? Does anyone have an idea what kind of things to look for? Sure - not that I have worked out in any detail how this would do what you're seeing, but it's easy to do and often enough works. Compile with RTS options enabled and invoke with RTS option -V0. That will disable the runtime internal timer, which uses signals. The flood of signals from this source can interrupt functions that aren't really designed to deal with that, because in a more normal context they don't have to. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd FFI behavior
[ ... re -V0 ] Thanks, this solved the problem. I would like to know more about what the signals are doing, and what am I giving up by disabling them? My hope is I can then go back to the dll expert and ask why this is causing their library a problem and try to see if they can solve the problem from their end, etc. I'm disgracefully ignorant about that. When I've been forced to run this way, it doesn't seem to do any very obvious immediate harm to the application at all, but I could be missing long term effects. The problem with the library might be easy to fix, and in principle it's sure worth looking into - while the GHC runtime delivers signals on an exceptionally massive scale, there are plenty of normal UNIX applications that use signals, maybe timers just like this for example, and it's easy to set up a similar test environment using setitimer(2) to provide the signal bombardment. (I believe GHC actually uses SIGVTALRM rather than SIGALRM, but don't think it will make any difference.) But realistically, in the end sometimes we can't get a fix for it, so it's interesting to know how -V0 works out as a work-around. I hope you will keep us posted. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
