We may see fewer travis failures if we can run the testall target sequentially. Perhaps the default can be 2 workers, but there could be a makefile variable to specify the number of workers.
I believe that one of the points of making these run in parallel was to force the exercising of parallel stuff so that it wouldn't be ok to break it casually anymore.
This was my motivation for filing this issue. Perhaps this needs to be tackled in a different way.
That link is not loading for me. Can you summarize and/or copy/paste what the problem is?
And no, it is not ok to have the option to run a weaker version of the tests to make them pass. That doesn't make sense.
$ cd /tmp/julia/share/julia/test && /tmp/julia/bin/julia runtests.jl all
ERROR: readcb: connection reset by peer (ECONNRESET)
in _uv_hook_readcb at stream.jl:207
in process_events at stream.jl:312
in event_loop at multi.jl:1381
in anonymous at client.jl:284 From worker 3: ERROR: connect callback: connection refused (ECONNREFUSED)
From worker 3: in default_connectcb at socket.jl:251
From worker 3: in _uv_hook_connectcb at stream.jl:154
From worker 3: in process_events at stream.jl:312
From worker 3: in event_loop at multi.jl:1381
From worker 3: in start_worker at multi.jl:887
From worker 3: in process_options at client.jl:180
Aha. You know, maybe we should use named pipes or unix domain sockets between processes on the same machine, for performance and to circumvent posible network-related issues like this.
My other motivation for a Makefile variable for the number of workers was that on bigger machines, I can use more workers and complete the tests quicker.
I don't think we really need this.