I suppose my question concerns the more general question of how to create
OS-managed threads in GHC. As I understand it, GHC's concurrency model
only exposes its RTS-managed internal threads, which are distributed
somehow to OS threads by the scheduler, and this is the source of my
timeout problem, because the scheduler never runs. Contrast this with
plain Linux C, where we can do something with pthread_create to call a
function in an OS-managed thread directly. 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.
Ryan
On Sat, Nov 17, 2018 at 3:21 PM Ryan Reich
I want to time out a pure computation. My experience, and that described in various previous questions here and elsewhere (the best of which is https://mail.haskell.org/pipermail/haskell-cafe/2011-February/088820.html), is that this doesn't always work: for instance,
timeout 1 $ evaluate $ let x = 0 : x in last x
does not time out because, apparently, the fact that the expression evaluates in constant space (i.e. never allocates) means that it never yields to the timeout monitor thread that would kill it.
The solution that is described in the other iterations is to embed checkpoints in the expression that do allocate, giving the RTS a chance to switch contexts. However, in my application, the expression is /arbitrary/ and I do not have the freedom to inject alterations into it. (Don't argue this point, please. The expression is arbitrary.)
How can I time out a tight loop like the above? Clearly, it can be done, because I can, say, alt-tab over to another terminal and kill the process, which exploits the operating system's more aggressively pre-emptive scheduling. Is there a solution using bound threads, say 'forkOS' instead of 'forkIO' in the implementation of 'timeout'? Unix signals? Some FFI-based workaround? Etc. Keep in mind that notwithstanding that comment, I don't actually want to kill the whole process, but just the one evaluation.
Thanks in advance, Ryan Reich