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

[H.J. Lu]

On Fri, Sep 28, 2012 at 9:13 AM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> 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.

Please don't inline __get_unique_id() so that it can be
optimized via IFUNC.

Thanks.

-- 
H.J.