[Haskell-cafe] Optimizing a high-traffic network architecture

[Joel Reymont]

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/