This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]