The usual picture is that thread is for CPU-bound and async coroutine for I/O-bound. Here, I believe I/O means anything goes through syscall so spawning subprocesses is included, even though the work inside the subprocess is CPU-bound. So,
@async etc.) seems to be the right choice to me. I expect Julia to handle multiple concurrent
reads since it uses
libuv (which communicates with kernel to switch to the I/O that is ready automatically).
As for the
pmap, I think it uses async coroutines underneath to communicate with Julia sub-/remote processes. So if you spawn a subprocesses inside
pmap, I think you are adding additional syscalls and it’s likely to slow down your program (though maybe that’s negligible).
Side notes: I think I/O-bound usually means the number of concurrent works is too large compared to the number of threads that the kernel can handle, as in web services. Since a process is more expensive than a thread, if you are launching processes then maybe it’s a bit misleading to call it I/O-bound or intensive. But, as async is more stable API than threads in Julia, why not use async?