Amit Murthy
Amit Murthy
JuliaLang/julia#3680 can be partially worked around by - having errors during deserialization send back a specific error, say `DeserializationError` before closing the connection. - The other end prints the error...
Bump. JuliaLang/julia#3680 is closed. Implement local-by-default loading?
At least the worker should not terminate abruptly, it should give a clean error message. The module PTools was not even required on the workers. The closure had some references...
How about an additional keyword argument to `addprocs` called `pkgsync` ``` addprocs(n, pkgsync=true) # The default. All packages currently loaded on 1 are loaded on the worker addprocs(n, pkgsync=false) #...
Julia users link regarding the same issue - https://groups.google.com/d/msg/julia-users/-Y1rc8gkrgo/r6w5f144BkMJ
Related - https://github.com/JuliaLang/Distributed.jl/issues/20
This is not yet a PR. Will convert it into a PR if folks are OK with the general design.
> Would that be stepping on your toes? Perish the thought. No issues whatsoever. I would initially focus just on the distributed "progress meter". Removing failed from the cluster currently...
- The out-of-band communication needs to be in a separate thread - `reset` is not simple. Consider this - Separate tasks on pid1 write msg1, msg2 and msg3 to pid2...
Why do we need both? Won't just using frame delimiters be enough? As for the possibility of a (extremely unlikely) collision, it is to be noted that it exists only...