Re: after ids

Hi Alexandre,

On 07/07/2008, at 16:08, Alexandre Ferrieux wrote:

> On 7/6/08, Daniel A. Steffen <das@...> wrote:
>>
>> All the implementations of relative timers in the OS (nanosleep(),
>> pthread_cond_timedwait_relative_np() etc) are based on this  
>> reference.
>
> So, the shell loop 'while :;do sleep 1;echo foo;done' should have
> visible quirks when someone sets the date, right ?

no, why? that's a relative timeout, /bin/sleep relies on nanosleep()  
and is not affected by calendar time changes (i.e. settimeofday() or  
adjtime())

the 'absolute' in mach_absolute_time() may be confusing matters,  
that's the monotonic time reference for relative time intervals (i.e.  
differences of m_a_t() values), whereas absolute timers are calendar  
time based.

However, on Darwin at least it turns out that even the APIs that take  
an absolute time to wait (like pthread_cond_timedwait()) in fact just  
wait for the relative interval to the value of gettimeofday() at the  
start of the call (i.e. if calendar time is adjusted/changed during  
the waiting, the kernel does not update the timeouts AFAICT).

> Is the timeout in select() also based on this absolute clock ?

yes, again a relative timeout, c.f. xnu/bsd/kern/sys_generic.c (the  
timeout is converted to the m_a_t() scale, added to the current  
m_a_t() and a kernel timer is scheduled to wakeup the calling thread  
at that deadline).

> That may be another reason to reform the threaded notifier, if you
> allow me that digression 

yes, still working on that one, been busy...

>> Darwin has pthread_cond_timedwait_relative_np() for exactly this
>> purpose, I don't know if other systems have something equivalent.
>
> Don't know either but please notice that going to select()  
> everywhere would solve the problem uniformly.

yes, but you would loose all the advantages of the current threaded  
notifier model (as discussed at length here before), which IMO would  
be much worse than the absolute/relative timer problems, esp. if we  
can find equivalents to pthread_cond_timedwait_relative_np()...

> The non-threaded unix notifer has no problem with relative timers,  
> it's just that currently the value is recomputed based on absolute  
> time when it needs be.

However, if you actually want absolute timers (as the current [after]  
implementation appears to), using select() may be incorrect unless you  
can find a way to be woken up when the gettod base changes. On Darwin  
a host notification is sent when calendar time is changed via  
settimeofday() (but not for adjustments due to adjtime()), I don't  
know if something similar exists on other platforms.

>> (converting next absolute timer fire to a relative
>> time interval may result in waiting for too long if there are changes
>> to the gettod base).
>
> That's exactly what happens today in Windows and unthreaded unix,
> since WaitForMultiple* (resp. select()) both take a relative timeout.
> See TIP302.

yes, I know, my question was what to do if in presence of _both_  
absolute and relative timeouts (e.g. if your -robust option in TIP302  
were adopted in addition to the current [after] based on absolute  
timers).

Cheers,

Daniel

--

-- 
** Daniel A. Steffen                   **
** <mailto:das@...>  **


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08