locked thread in spawn about distributed-process HOT 6 CLOSED

I don't think the issue is that we cannot spawn a closure on master -- when I run your example with just a single node (i.e. the master only), and stick in a threadDelay to make sure the master does not exit before it gets a chance to print the log message, it prints the result of isPrime and then shows the same MVar error that you're showing. I'll investigate.

from distributed-process.

Awesome.

from distributed-process.

It's related to spawnLink (as opposed to spawn).

from distributed-process.

Yes I saw it in every variant/extension of spawn too.

from distributed-process.

Right, so: the new implementation of Cloud Haskell follows the semantics described in "A Unified Semantics for a Future Erlang". In this semantics, linking makes no distinction between regular termination and abnormal termination. In other words, if you link to a process, and that process dies normally, you die too. This is appropriate for slave processes that link to their masters, where the master should never terminate (masters should monitor their slaves, not link to them). In your example, you are linking to the processes that compute the prime numbers. As soon as this process terminates, the process that spawned it will die too.

The "thread blocked indefinitely" exception you were seeing was a bug, however. The backend starts the master process using "runProcess", which waits for a process to finish -- but it didn't take into account abnormal termination and would beb blocked indefinitely when the process threw an exception. I have fixed this and released it as 0.2.2.0 to Hackage.

If you run your example again (and insert a threadDelay to give the spanwed processes a chance to do anytihng) you will find that the program will now terminate quietly, possibly after or possibly before the log message.

So in summary: you shouldn't use spawnLink here, but you did find a bug. Thanks for the report :)

from distributed-process.

Awesome thanks for the update. I was mostly concerned because I didn't see the same behavior in the original 'remote' package (it waits for the spawnLink'ed processes to finish before the main exits) and also the mvar thread lock message.

from distributed-process.