Bulat, On Dec 14, 2005, at 9:00 PM, Bulat Ziganshin wrote:
TZ> You don't have to check "every few seconds". You can determine TZ> exactly how much you have to sleep - just check the timeout/ event with TZ> the lowest ClockTime.
this scenario don't count that we can receive new request while sleeping and if this thread services different waiting periods, the new message may require more earlier answer
The scenario above does account for the situation that you are describing. We will always retrieve the minimum key and will fire the timer as long as it has expired. My timers don't need to be precise so this works for me. checkTimers :: IO () checkTimers = do t <- readMVar timers -- takes it and puts it back case M.size t of -- no timers 0 -> threadDelay timeout -- some timers _ -> do let (key@(Timer time _), io) = M.findMin t TOD now _ <- getClockTime if (time <= now) then do stopTimer key try $ io -- don't think we care return () else threadDelay timeout checkTimers
i repeat my thought - if you have one or several fixed waiting periods (say, 1 sec, 3 sec and 1 minute), then you don't need even to sort requests - just use one waking thread for each waiting period and requests will be arrive already sorted. in this way, you can really sleep as Tomasz suggests
I do not have several fixed waiting periods, they are determined by the user. Joel -- http://wagerlabs.com/