Support something like myid() to know what worker you are

[nickrobinson251]

suppose you want to know if you're coordinator or worker, e.g. you might want to write something like

get_config_file() = myid() == 1 ? "location1/file.txt" : "other/location/worker_file.txt"

or suppose you want to have workers only try to access "their" range of ports:

get_a_port() = (start = 6000+100*myid()); stop = start+99; rand(start:stop))

i.e. you don't know which worker will run this code, but you want the output to be different for each worker and
(for the first example) ideally the output would allow the coordinator (non-worker) process to be identifiable (e.g. myid() == 1), and (for the port example) for the values to be evenly spaced. We could use Libc.getpid, but it a pid doesn't have these extra properties like myid() does.

[quinnj]

I think you could manage this fairly easily from the coordinator, like:

using ConcurrentUtilities

const myid = 1

workers = [Worker() for _ = 1:nworkers]
@sync for (i, w) in enumerate(workers)
    Threads.@spawn begin
        _i = $i
        remote_fetch(w, :(const myid = $_i)
    end
end

that probably works for a script. If we're talking about putting this in a library, then it still shouldn't be too bad, because you create some kind of initworkers(n) function that basically does the above.

That's not to say we shouldn't change anything in ConcurrentUtilities; we could, for example, do something like eval const WORKER = true on each worker when we initialize the process or something, so you'd have a way to at least tell whether the current Julia evaluator is a worker or not. Or maybe a Ref{Bool} in ConcurrentUtilities w/ an accesor function like ConcurrentUtilities.isworker()? And we could set the Ref when we initialize the worker?

I'm open to ideas here. I think what I'd like to avoid though is the coordinator having to have a global pool where it keeps track of all the workers with all this global state around their IDs and such. I think I prefer leaving any more sophisticated worker coordination/management/pooling up to users in the calling context. I think the Distributed code that does all this just really overly complicates things.