Polling channel communication permanently blocks? about hopac HOT 4 CLOSED

I haven't yet tried to run the code, but I believe the problem is that the poll job never blocks. It completely hogs the one core it is running on and due to the way the cooperative scheduler works, the receiver job never gets a change to run—even if there are multiple cores. Note that if you were running this with only a single core, then the deadlock would be quite reasonable, so I think it can be argued that this behavior is fundamental to how a cooperative system works.

If you add something that blocks the poll job, such as

let poll = job{
    let counter = ref 0
    for i = 0 to 999 do
        let! res = Ch.Try.give c ()
        if not res then
          do! Timer.Global.sleep (TimeSpan.FromSeconds 0.0001)
          counter := !counter + 1
    printfn "%A" !counter }

the receiver job gets a chance to run. Does the polling job in your actual program also block after a finite number of polling operations?

from hopac.

Now that I have had my first sip of coffee, I noticed there is a bug in the newly introduced Ch.Try.give operation. Just a moment and I'll fix it.

from hopac.

Thanks for reporting the bug and sorry for the trouble!

I only tested the polling operations quickly with F# interactive and should have added some more substantial code to exercise those code paths.

Note that the discussion about polling loops needing to have some blocking operations is something that needs to be kept in mind although it isn't a problem in your example code, because it only does a finite number of polls.

from hopac.

Thanks a lot! This fixes it. And as you described above, the fact that the polling job never yields control means that only the first value given is read. This is expected.

from hopac.