Erlang: are many timers alright?

Question

I have a gen_server process that supports the pool, for each incoming request I need to examine the pool to see if there is a match for this incoming request, if any, the matching one is removed from the pool and the answers to both requests; if they are not, a new request is sent to the pool for further study.

The biz logic requires that if an R request sits in the pool for T seconds without agreeing, I need to answer R by saying something like "I can't find a match for you."

Ideally, I want to do this using timers, in particular, for each incoming request, if there is no match, put it in the pool as before, but also start the timer to tell gen_server to delete it, if the time is, of course, if it is agreed later, the timer must be canceled.

My concern is that if there are many unsurpassed requests in the pool, then there will be many timers, will this (too many timers) become a problem?

Answer 1

There have been major improvements in the implementation of timers in R18 .

  Besides the API changes and time warp modes a lot of scalability and performance improvements regarding time management has been made internally in the runtime system. Examples of such improvements are scheduler specific timer wheels, scheduler specific BIF timer management, parallel retrieval of monotonic time and system time on systems with primitives that are not buggy. 

special timers for the scheduler - exactly what is interesting in your scenario. I doubt that you have come up with a better solution to your problem in Erlang or another language / environment. Therefore, your decision should be fine when you use R18 or newer.