httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Covener <cove...@gmail.com>
Subject Re: asynch websocket, how to timeout?
Date Tue, 18 Feb 2014 14:29:51 GMT
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 <covener@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
> covener@gmail.com



-- 
Eric Covener
covener@gmail.com

Mime
View raw message