httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Takashi Sato <taka...@tks.st>
Subject Re: svn commit: r1605369 - /httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c
Date Thu, 26 Jun 2014 03:23:26 GMT
>>> 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 can't say it is really really safe now.
But IMHO if it is not safe, I think we should fix, modify and enhance
the MPM. MPMs should guarantee such safety.
I will read and test event.c more and want to be sure.

In the future I want to make more modules async.
(mod_proxy_* and mod_cgid)

> From the context of the diff -- maybe if it's non-zero (non default),
> we could use the old path directly.

I tried.
At first ProxyWebsocketAsyncDelay is effective, but after go async
 (trace1 log "AH02542: Attempting to go async"),
ProxyWebsocketAsyncDelay is ignored.

I guess making it effective again is easy, maybe I have to add
a few code.
But I still doubt whether it is useful for users, though it may be
useful for us for debugging or developing.

Mime
View raw message