Wait, it is a dumb question. Never mind. David
On Mon, Sep 6, 2021 at 7:58 AM David Boyce <david.s.bo...@gmail.com> wrote: > > One possibility would be for make to write out bytes with values > 0,1,2,3... then when it gets to 255 start over again ... > > I hope this sin't a dumb question, I've never worked with the job server, > but hy not use the value of the file descriptor from the parent side as the > token to send down the pipe? Still limited to 255 of course, same wrapping > problem, but the fd is guaranteed unique and I could imagine cases where > that data might come in handy for debugging via strace or whatever. > > David > > On Mon, Sep 6, 2021 at 7:37 AM Paul Smith <psm...@gnu.org> wrote: > >> On Fri, 2021-08-13 at 14:14 +0100, Howard Chu via Bug reports and >> discussion for GNU make wrote: >> > I'm looking for a way to expose a job ID number to the individual >> > jobs, in a consecutive range from 1-[number of jobs]. Not just >> > unique numbers, for that we could just use $$ already. The purpose >> > is to e.g. assign non-overlapping network port numbers when firing >> > off a number of client/server test scripts in parallel. >> > >> > Is there anything that could do this now, exposed as a Make variable? >> >> I don't see any way make can provide something like this, at least not >> using the model it does today. The current requirement is that each >> read from the pipe is of exactly 1 byte and there's no way to guarantee >> a unique value in a single byte of data if there are >256 possible >> values of course. >> >> One possibility would be for make to write out bytes with values >> 0,1,2,3... then when it gets to 255 start over again: this would give >> unique values for any -j <= 256 and you'd only have to worry about >> wrapping for very large values of -j. >> >> One reason I'm not excited about this idea is that I've been seriously >> contemplating switching from the current pipe-based jobserver control >> method, to using POSIX named semaphores instead (at least as the >> default). There is support for these in most systems these days, and >> it's already how Windows works (with the Windows equivalent). The >> advantage here is it's just easier in lots of ways to not have to pass >> open file descriptors between make invocations. I could use a named >> pipe but semaphores are more obviously built for this. But of course >> there's no possibility of uniquely identifying a semaphore lock. >> >> The other downside of using a semaphore is I was thinking of >> implementing a "fast fail" feature where as soon as any make in the >> jobserver domain died all the other makes would stop quickly as well. >> This is something people seem to really want. One way to implement >> this is to write "error bytes" into the jobserver pipe when we've hit >> "failure mode"; whenever a make instance reads the "error byte" instead >> of the "normal byte" it would finish any outstanding jobs then stop. >> >> This is pretty straightforward although it's not ideal: make can >> potentially do a lot of work with its single token without trying to >> read from the jobserver for example. >> >> Of course a single semaphore can't help here. If we go with "named X" >> we'll need a directory to hold it; one idea would be to write a >> "failed" file into that directory that all make's could check for. >> >> >>
