This is the mail archive of the
mailing list for the glibc project.
Re: Help me to understand the POSIX timers
george anzinger <email@example.com> writes:
> > linuxthreads/sysdeps/posix/timer_*
> The timer_* seems to be in linuxthreads/sysdeps/pthread/*
> timer_settime calls __timer_thread_wakeup() which I can not find.
??? It's right in front of your eyes:
linuxthreads/sysdeps/pthread/timer_routines.c. Simply use grep.
> I have the kernel patch but I have yet to worry about process or thread
What do you think are "process or thread timers"? There is nothing
like this. There are POSIX.1b timers which are using underlying
clocks of the users choice, they can be interval timers, and they can
react in threee different ways to timer expirations.
> I am trying to explore if it might be wise to put these in user
> land. I hesitate to drop support for them since they are already, at
> least conditionally, present in glibc.
I don't understand a word. The clocks must be provided by the kernel.
Based on them the kernel provides timer services. Obviously the
kernel cannot create threads so handling SIGEV_THREAD must be handled
by the user level code. Everything else the kernel can do and
therefore most of the action of the timer_* functions is to call the
kernel. The current implementation is just there as a crude
replacement for non-existing kernel support. It's a horrible,
inaccurate, slow, resource-consuming hack.
> On the other hand, I haven't check to see if _POSIX_CPUTIME and/or
> _POSIX_THREAD_CPUTIME are defind.
These are clocks, no timers. They are supported on some architectures
but obviously cannot be handled by timers without kernel support since
the resultion is simply not there.
> On a related issue, do you know if there are man pages for clocks &
Read the standard. It even is in man page format.
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------