Subj : Re: pthread_cond_signal in a signal handler?
To   : comp.programming.threads,comp.unix.programmer
From : Sean Burke
Date : Fri Jan 14 2005 11:35 pm


red floyd <no.spam@here.dude> writes:

> Sean Burke wrote:
> >>>ptjm@interlog.com (Patrick TJ McPhee) writes:
> >>
> >>>In article <4sEBc.6701$86.1551@newssvr27.news.prodigy.com>,
> >>>red floyd  <no.spam@here.dude> wrote:
> >>>
> >>>% I'm trying to implement a generic timer queue using itimers, and to 
> >>>% avoid doing a ton of work inside the signal handler, I'd like to have a 
> >>>% thread waiting on a condition variable, and signal it when the itimer 
> >>>% goes off.
> >>>
> >>>Leaving pthread_cond_signal aside, you need to lock a mutex, update a
> >>>predicate, and unlock the mutex if you want to get the semantics of
> >>>the condition wait right, and you can't do any of that in a signal
> >>>handler.
> >>>
> >>>On the other hand, you could set up a dedicated timer thread and have
> >>>it block on pthread_cond_timedwait.
> >>
> >>I have an implementation of this method (dedicated timer thread blocking
> >>on pthread_cond_timedwait()) that you are free to use.
> >>Look in
> >>
> >>	ftp://ftp.xenadyne.com/Nifty.tgz
> >>
> >>at nft_task.c.
> > 
> > 
> > Oops - 	ftp://ftp.xenadyne.com/pub/Nifty.tgz
> > 
> > -SEan
> 
> Sean and Joe: could you take a look at 
> http://alumni.cse.ucsc.edu/~scottn/timerthread.cpp and see if you can 
> see anything obviously wrong?  My embedded q&d test case seems to work 
> properly.
> 
> I'd really appreciate it.

Looks good to me, although I didn't see where you free the Timer instances,
unless timer_queue.pop() does this. Also, you might consider whether you want
to spawn a new thread to execute each timer instance. You could call the
task function inline, and that function could call create_thread() or not,
depending whether the function is going to perform a lengthy task.

-SEan

.