timer_create fails (return=-1 errno=0)

Rich Felker dalias at aerifal.cx
Thu Oct 20 03:49:13 UTC 2011


On Wed, Oct 19, 2011 at 08:53:19PM +0000, Grant Edwards wrote:
> >> It's way simpler to use SIGEV_SIGNAL and then set up a thread that
> >> calls sigwaitinfo() in a loop waiting for the timer signal.  The
> >> kernel's quite good at keeping track of timers and figuring out when
> >> the next one times. :)
> >
> > That works, as long as you block the signal in all other threads.
> 
> Yes: all threads have the signal blocked, and one thread calls
> sigwaitinfo() to wait for that signal.  This has the advantage that
> there is no thread-creation going on once things are all set up and
> running.  Thread creation probably isn't that big a deal, but the
> painful memory of process-creation overhead on VMS never really goes
> away...

Note this is actually a major advantage over glibc's SIGEV_THREAD
implementation. Since thread creation happens at timer delivery time
and can fail, you can lose timer events, and they're not reported by
timer_getoverrun which is purely kernel-level. The ideal
implementation of SIGEV_THREAD, I believe, is to have a dedicated
thread per timer, and *attempt* to deliver the event in a new thread
(so multiple expirations of the same timer can run in parallel),
falling back to running the callback in the timer thread (and letting
overruns accumulate at the kernel level) if thread creation fails.
Some hacks are necessary when running the callback in the timer
thread, though, to prevent pthread_exit or cancellation from
terminating it and breaking all future use of the timer.

Rich


More information about the uClibc mailing list