This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4] Make bindresvport() function to multithread-safe
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