so one way to handle no allocation things playing nicely with the scheduler is to compile haskell code with -fno-omit-yieldsthis will generate code which has scheduler yields even in loops which dont allocatecheers!-Carter_______________________________________________On Mon, Nov 19, 2018 at 3:27 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:On Mon, Nov 19, 2018 at 11:26:17AM -0800, Ryan Reich wrote:
> I suppose my question concerns the more general question of how to create
> OS-managed threads in GHC. [...]
> 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.
I was just reading:
https://cs.nyu.edu/~mwalfish/classes/14fa/ref/boehm05threads.pdf
which may offer some insight. The runtime needs to be able to
provide a consistent memory model to threads. Just running something
in an OS thread that's managed by the RTS could make that difficult,
and it is not clear how that cooperates with garbage collection.
But to your point, when adding threads to your example, I find that
the infinite loop then runs concurrently in all the threads, and
the timeout never happens. While:
Replacing: let x = 0:x in last x
with: let ! x = 0 + x in x
does make timeout work, so it is not entirely obvious which pure
computations can be timed out.
--
Viktor.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.