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 
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 < <>> 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. 
>       Director, Highland Sun
>       Chief Architect, OpenLDAP

  -- Howard Chu
  CTO, Symas Corp. 
  Director, Highland Sun
  Chief Architect, OpenLDAP

Reply via email to