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/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
