Hi, ----- Original Message ----- From: "JohnQ" <jqs@jqs.net> To: <boost@lists.boost.org> Sent: Thursday, June 04, 2009 11:09 AM Subject: [boost] first review submission of timer_queue.zip

Hi, Thanks for pointing me to the submission requirements page... I just uploaded timer_queue.zip to boost vault for first review. Haven't got everything shipshape yet but I'm hoping I've satisfied enough of the requirements so I can start getting some feedback on functionality. If not, let me know so I can rework and resubmit.

In essence, timer_queue is a library for creating timers that fire at some arbitrary time in the future and hand you back a void* that you provided when you created the timer. Timers can be deleted before they fire by providing an id (can be non-unique) when you create a timer that can be used to delete particular sets of timers later on.

Thanks to any who take the time to review this and help me make it better.

Why the call_back is associated to the timer_queue and not to the timeout? Do we really need several timer queues? Shouldn't only one be enough? IMO the class timer_queue muts be hiden to the user. The interface I would like to use is something like, auto h = after_call(miliseconds(10), f, x, y); or auto h = at_call(now()+miliseconds(10), f, x, y); if (some condition) { h.interrupt(); } The user should be also able to wait until the timeout has expired and the function called. So h.wait() will synchronize with the end of the function call f(x,y). If in addition f returns something the following should also be correct auto res = h.get() So the handle returned by auto h = after_call(miliseconds(10), f, x, y); must implement the future interface (an asynchronous completion token). There are classic implementation using a well instead of a queue which make insertion independent of the number of active timers (see for example "Redesigning the BSD Callout and Timer Facilities" by Adam M. Costello, George Varghese http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=B5202FC949FF3EDB0E789F68F509950C?doi=10.1.1.54.6466&rep=rep1&type=pdf). Best regards, Vicente Best, Vicente