[PATCH v4] Make bindresvport() function to multithread-safe
H.J. Lu
hjl.tools@gmail.com
Fri Sep 28 16:00:00 GMT 2012
On Fri, Sep 28, 2012 at 8:55 AM, Pedro Alves <palves@redhat.com> wrote:
> 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. ;-)
>
We should add an new function to return a random number,
which can be optimized via IFUNC for hardware random
generator.
--
H.J.
More information about the Libc-alpha
mailing list