1011 Subj : Re: Help with timers/signals To : comp.programming.threads From : Sean Burke Date : Tue Mar 15 2005 02:16 am "vinay" writes: > Sean Burke wrote: > > "vinay" writes: > > > > > Hi guys, > > > Im new to programming with linux and its timers and signal > handlers.Can > > > any one suggest a possible solution to the problem im having.The > > > problem is described as follows > > > I have an array of queues.Say 10.Now i go thro this array 1 by 1 > and > > > dequeue elements from each queue.This is simple.My problem now is > this > > > dequeuing.Every element needs to be dequeued at a particular point > in > > > time.Hence i need to set different timers/signals for the different > > > times that each element will be dequeued.Is there any way of > specifying > > > this functionality using signals/timers.Example:i need to specify > an > > > alarm that goes off at 20ms for the 1 element then at 50ms(after > 30ms) > > > for the 2nd element then at 10ms(this timer will go off first > actually) > > > for the 3 element.And the action for the alarm is the dequeue > function > > > that will dequeue the element whose timer expired from the > particular > > > queue. Also Can this queue parameter also be passed to the handler > > > function?? cos as per the documentation for the signal handler it > takes > > > only 1 argument signum. Is it possible to send more arguments to > the > > > handler from the signal call?? > > > I dont know if its possible but is there a way of specifying user > > > defined signals in linux.I was thinking of having 10 user defined > > > signals for the 10 queues that i have.And every time a timer > expires in > > > a particular queue i need to send the signal associated with that > > > queue.Is this possible in linux.I have just come across the alarm > and > > > some other standard signals which are generated and hence this does > not > > > suit my need. > > > Thanx in advance for ur suggestions ...... ive been racking my > brains > > > for this one...would indeed be a great help to get some pointers on > > > this. > > > thanx and kind regards > > > vinay > > > > While timers may look like they should be a good solution to this > > problem, I have also found that in practice they aren't very easy > > to use, particularly in view of the issues that attend the use of > > signals in threaded code. > > > > The Nifty library contains thread-based timer package that should > > be a good match to your requirement. The code is free to use, and > > you can download it from > > > > ftp://ftp.xenadyne.com/pub/Nifty.tgz > > > > -SEan > > Hi Sean, > Thanx a million for the library.It is really helpful.But i do have some > questions still though. The stuff that i explained im doin ..im doin > that in a separate thread in my program.Now ur code also uses threads i > think.So will the working of the nft_task_schedule and the > nft_task_cancel be unpredictable when using these function from another > thread in my program.Cos right now the results that im getting are a > little weird. > Thanx for the idea and code ..was really helpful > Regards > Vinay The tasks that you submit to nft_task_shedule() are executed in a separate thread that is spawned internally by the first call to nft_task_schedule(). So tasks will execute asynchronously with respect to your other threads, and you must implement mutual exclusion for any shared data, and ensure that the task thread is not blocked indefinitely. The handle that nft_task_schedule() returns may safely be canceled from any thread, and the nft_task_cancel() call is guaranteed to return the task argument if the task was canceled successfully, or NULL if the task has already executed. Of course, this means that you must pass a non-NULL task argument in order to distinguish whether the task was canceled prior to execution or not. I hope that answers your question. If not, please describe the wierd results in greater detail. -SEan . 0