Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 12106 invoked from network); 22 Jan 2004 14:15:59 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 22 Jan 2004 14:15:59 -0000 Received: (qmail 41775 invoked by uid 500); 22 Jan 2004 14:09:39 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 41741 invoked by uid 500); 22 Jan 2004 14:09:38 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 41594 invoked from network); 22 Jan 2004 14:09:37 -0000 Message-ID: <400FD99F.8060708@algroup.co.uk> Date: Thu, 22 Jan 2004 14:09:35 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wray Ferrell Cc: dev-apr Subject: Re: APR - Setting Generic Timers References: <400797E1.2010208@pisa.iol.it> <4008021C.3020608@wstoddard.com> <400D4BA9.3000600@pisa.iol.it> <400D4EC2.4080108@cisco.com> <400D55E6.4000801@cisco.com> In-Reply-To: <400D55E6.4000801@cisco.com> X-Enigmail-Version: 0.82.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Wray Ferrell wrote: > Having spent a few days looking at what APR has > to offer, I noticed that there does not appear to > be anyway to set a generic timer. The functions > apr_thread_cond_timedwait put the thread to sleep > while waiting for either the condition to be fullfilled > or the timeout to occur. What I am looking for, and > feel sure I overlooked, is the ability for a thread to > set a timer with an expiration and a callback function. > > For example, use a VOIP phone using the SIP protocol. > The phone sends out an INVITE and then sets a timer > with a callback function. If that timer pops the phone > knows that no response to the initial INVITE has been > recieved so the phone will re-transmit the INVITE. > However this thread cannot sleep because it must still > process data from the DSP, the user could decide to > hangup, etc... > > How would this be modeled in APR or is APR a > purely event-driven model? The first question to ask is: is this a facility that can be provided on all (or at least most) systems we support? Because if it isn't, it isn't a candidate for APR. If it is, then we would certainly consider adding it. Don't think we do it right now, though. OTOH, the thing I'm trying to resolve (slowly) is how to do cross-platform select() or poll() that works on more than just sockets (in particular, pipes, too). With that, you can get what you want using the time-out argument. Which is probably better and simpler anyway. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff