+1... On Feb 18, 2014, at 9:29 AM, Eric Covener <cove...@gmail.com> wrote:
> I think this needs to be handled as 1 API within event, taking the > existing API and adding a timeout, rather than having the caller > register separate timed callbacks. > > This way, event can mark the timeout as no longer needed before > pushing the first event to the worker. This way there's no question > about the timers and callbacks running in different orders. > > When we are pulling timer events off the timer list, we can just > ignore ones that are no longer needed. The ignore flag can be set w/o > the lock rather than trying to fish it out of the list. > > On Sat, Feb 15, 2014 at 1:45 PM, Eric Covener <cove...@gmail.com> wrote: >> There is a deficiency in the asynch websocket stuff in trunk. >> >> For background, the websockets proxy acts like mod_proxy_connect after >> the initial setup. It can ask event to watch both sockets for it and >> return SUSPENDED. >> >> But there is no separate timeout if neither end sees activity, so the >> request can stretch out a long time. >> >> My only idea here is: >> >> Fire off some separate timer event at a relatively long interval to >> see if the pair of sockets has been idle for a very long time (it >> would have the same baton as the other callback) >> >> Optionally, the timer event could be cancelled when the socket >> callback fires -- we would need to add a way to cancel those events. >> >> Otherwise, it would just try to grab the invoke mutex then check to >> see when the last socket activity was. >> >> Anybody have better ideas? >> >> >> -- >> Eric Covener >> cove...@gmail.com > > > > -- > Eric Covener > cove...@gmail.com >
