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

[Pedro Alves <palves at redhat dot com>]

On 09/28/2012 04:35 PM, Carlos O'Donell wrote:
> On Fri, Sep 28, 2012 at 11:28 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 09/28/2012 03:45 PM, Carlos O'Donell wrote:
>>> On 9/28/2012 10:42 AM, Pedro Alves wrote:
>>>> On 09/28/2012 03:27 PM, Carlos O'Donell wrote:
>>>>> Call this __get_uid(), since that's what you're doing.
>>>>
>>>> That's terribly confusing with getuid.
>>>
>>> And your suggestion is?
>>
>> Some:
>>
>> __get_initial_port
>> __get_initial_port_dividend
>> __get_port
>> __get_port_dividend
>> __get_id_for_port
>> __get_id_for_initial_port
>> __get_id_for_initial_port_dividend
>> __get_pid_for_port
>> __get_pid_for_initial_port
>> __get_pid_for_initial_port_dividend
>>
>> (initial, because if the first attempt fails, bindresvport
>> increments and tries again, etc.)
>> (dividend, because this doesn't really return a port,
>> but the dividend to be used in a modulus operation.)
> 
> How about __get_unique_id?
> 
> The macro returns what should be a unique ID used for the hash.

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).

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.  ;-)

-- 
Pedro Alves