On Wed, Jun 25, 2014 at 12:55 PM, Takashi Sato <[email protected]> wrote: > 2014-06-25 21:33 GMT+09:00 Eric Covener <[email protected]>: >> On Wed, Jun 25, 2014 at 8:24 AM, <[email protected]> wrote: >>> Refactor asynchronous mod_proxy_wstunnel using pollfd returned by MPM. >>> r1601943 and r1605307 made Event MPM return woken pollfd, so async >>> wstunnel doesn't need its own apr_pollset_poll. >> >> If both sockets are readable, we'll go all the way through >> ap_mpm_register_socket_callback_timeout + locking queues and getting >> dispatched to a new thread to read the 2nd socket. > > So, you think the new code is poor performance than before? > Or are you afraid that the 1st and 2nd socket are proceed at the same time? > The latter doesn't happen, because event.c line 1968: > > /* We only signal once per N sockets with this baton */ > if (!(baton->signaled)) { > > so only the 1st socket is sent to worker thread.
I think hopping off that thread during a flurry of websockets activity could hurt but I can't say for sure. > >> I think this also prevents us from doing ProxyWebsocketAsyncDelay to >> stay on the thread because we no longer have a poll during the >> callback invocation. > > Yes, you are right, but, is ProxyWebsocketAsyncDelay needed? I don't know. It was more or less free at the time, and I was more anticipating what knobs might be useful. >From the context of the diff -- maybe if it's non-zero (non default), we could use the old path directly. -- Eric Covener [email protected]
