Hi, On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> >Why is that needed in a _general_ timeout API? What exactly makes it so > >useful for everyone and not just more complex for everyone? > > Because if a system call gets a timeout specification it needs to > verify its correctness first. Instead of doing that at the point > where it goes to sleep, that could be deep in an atomic section, > we provide a separate function [timeout_validate()] which is the > one you mention, to do that. > > Usefulness: (see the rationale in the patch), but in a nutshell; > most POSIX timeout specs have to be absolute in CLOCK_REALTIME > (eg: pthread_mutex_timed_lock()). Current kernel needs the timeout > relative, so glibc calls the kernel/however gets the time, computes > relative times and syscalls. Race conditions, overhead...etc. > > This mechanism supports both. That's why it is more general. Your patch basically only mentions fusyn, why does it need multiple clock sources? Why is not sufficient to just add a relative/absolute version, which convert the time at entry to kernel time? bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/