Re: [PATCH v4] Make bindresvport() function to multithread-safe

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Fri, Sep 28, 2012 at 11:55 AM, Pedro Alves <palves@redhat.com> wrote:
> I have trouble explaining what is "unique" about it: it's a
> per-process/thread/something unique id, from a pool that is
> hopefully at least as large as NPORTS, I get from context, but
> that's not encoded in the function name.  Actually, there's
> no requirement that the number is stable per-process/thread, is
> there?  If returning any random integer would be super cheap,
> that'd be a valid implementation too?  It'd be arguably better,
> since sequencial calls to bindresvport by the same thread
> would likely avoid the retries (not that that matters much).

You are confusing what should be with what is.

The function should be __get_random_number(), but I imagine the
original author considered it too expensive to use rand (not to
mention it might drain a common entropy pool).

The function is __get_unique_id(), because we want a fast and cached
per-process/per-thread unique number that avoids threads and processes
from starting the search for free ports at the same place.

> Anyway, just rambling.  __get_unique_id is a million times
> better than __get_uid.  If you like it, go for it.
> I would not have said anything if that had been the
> initial proposal.  ;-)

Ramble away. I don't judge anyone on Friday :-)

I agree that if we had a fast IFUNC random number generator (as H.J.
is suggesting) then using it here with a fast hash function would be
great.

I would review such a patch, but it would need to have performance
justifications. I also don't think this is a critical area where we
need help optimizing performance.

The reason I'm reviewing these patches is because Peng is working hard
to meet the needs of the community. I'm willing to meet half-way
because it appears there is a user need to have this function be
thread-safe. There is nothing in any standard that says this function
*can't* be thread-safe, just that it isn't in general. Given the
technology components we have, if we can make it thread-safe with
minimal performance impact (in a function that isn't really that
performance critical), then I'd be happy.

Good work so far Peng!

Cheers,
Carlos.