[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#3524) libldap multiple select() without reinitializing FD_SETs
I know of no implementation of select(2) which increases
the timeout. Some leave it alone. Others decrease it
by the amount waited. When they do, we take advantage
of that. If they don't, oh well.
My question is, does anyone know of an implementation
where the code behaves in an ill maner (e.g., beyond the
above)?
Kurt
At 09:47 AM 1/28/2005, Pierangelo Masarati wrote:
>>>According to the select(2) man page
>>
>> Is there any other reason for this change? Especially as it
>> applies to the timeout?
>>
>> On some systems, when EINTR is returned, the timeout is
>> decreased by the waited time. Otherwise, the amount of
>> time waited across the original and all restarts could be much
>> then the specified timeout.
>
>I think this might be an issue, although I haven't understood yet if the
>code actually needs to be fixed or not. I recall reading that note, for
>an unrelated project, and I decided to externally recompute the value of
>the timeout and reinitialize the value to avoid any portability problem.
>
>However, the issue might simply be in the wording of that sentence, which
>sounds a bit obscure to me (but my English might not be fluent enough...):
>
> ...
>
> On Linux, the function select modifies timeout to reflect
> the amount of time not slept; most other implementations
> do not do this. This causes problems both when Linux code
> which reads timeout is ported to other operating systems,
> and when code is ported to Linux that reuses a struct
> timeval for multiple selects in a loop without reinitial-
> izing it. Consider timeout to be undefined after select
> returns.
>
> ...
>
>I assume who wrote that couldn't be much clearer in such a short sentence,
>but the last statement is what usually gets impressed.
>
>p.
>
>--
>Pierangelo Masarati
>mailto:pierangelo.masarati@sys-net.it
>
>
> SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497