Christian Hujer wrote: > Hi, > > Have you considered using port 0 instead to tap into the ephemeral port range > and communicate that port somehow?
That would require starting up a server first, and somehow getting it to report its port# to us. But the server configs must know port#s in advance because they need to talk to each other. > > From what I understand, you want to use the job id as an offset to a base > port to choose a port from a range, right? That sounds non-portable to me, > spelling > all sorts of ports conflict trouble. Currently we use the range of 9000-9020. On a build/test machine we don't worry about conflicts, a developer has no business running conflicting software at the same time as building/testing our software. And of course, the baseport 9000 can be moved at will. > > Christian > > On Fri, Aug 13, 2021, 18:44 Howard Chu via Bug reports and discussion for GNU > make <bug-make@gnu.org <mailto:bug-make@gnu.org>> wrote: > > In my original jobserver implementation, I filled the job pipe with > up to 256 bytes, numbers from 0-255. The idea being that then make > could distinguish each job with a unique ID number. That idea got > thrown away when we decided to raise the limit to PIPEBUF (4096 on > traditional Unix, much larger now on Linux). > > 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? > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/