Can you start the server and get the port in the parent process, then fork
and run the tests from the child?
On Thu, Apr 23, 2015 at 11:21 AM, Cosimo Streppone <cos...@opera.com> wrote:
> On 23. april 2015 19:02, Tim Bunce wrote:
>
> > On Thu, Apr 23, 2015 at 05:59:34PM +0200, Cosimo Streppone wrote:
> >>
> >> When the fork + exec'd daemon chooses a random port, I need to be able
> >> to know which port it has bound itself to, and here lies the problem.
> >
> > Perhaps dodge the problem by not picking a random port. Have the parent
> > process look for free ports itself in some obscure part of the range.
> > Then pass that port number to the daemon. There's a very small race
> > hazard here but that seems quite acceptable under the circumstances.
> > Especially as you'll know you've hit it because the statsd daemon will
> die.
>
> Thanks Tim, I can certainly experiment with this idea.
> My hunch is that port clashes will still happen, but that
> needs to be verified.
>
> >> Basically I set an ENV variable such as $ENV{STATSD_PORT_FILE} with a
> >> temporary random file name.
> >>
> >> In the daemon startup code, if $ENV{HARNESS_ACTIVE} and
> >> $ENV{STATSD_PORT_FILE} are both there (since the daemon is spawned by
> >> the *.t script), then the port number is saved into the file name
> >> indicated by $ENV{STATSD_PORT_FILE}.
> >
> > How is "the port number is saved into the file" when you don't know
> > which port it has bound itself to?
>
> The daemon starts and binds using port 0. Still within the daemon code,
> I can then query for the used port, through regular socket calls.
> After that, I check for HARNESS_ACTIVE and STATSD_PORT_FILE
> and I write the port to the file indicated by STATSD_PORT_FILE.
>
> Of course I don't like that the statsd daemon code needs to know about
> this at all.
>
> Thanks,
>
> --
> Cosimo
>
>
