Date: Thu, 28 Mar 2002 23:47:06 +0100 (MET) From: Lars Christensen <larsch@cs.auc.dk> Subject: [webricken:82] Re: Help with a 408 error To: webricken@notwork.org Message-Id: <Pine.GSO.4.44.0203282344200.19882-200000@peta.cs.auc.dk> In-Reply-To: <20020327.044810.128894790.gotoyuzo@kotetsu.does.notwork.org> X-Mail-Count: 00082On Wed, 27 Mar 2002, GOTOU Yuuzou wrote: > In message <Pine.GSO.4.44.0203241341020.28805-200000@peta.cs.auc.dk>, > `Lars Christensen <larsch@cs.auc.dk>' wrote: > > > This approach seems appropriate to use the threads efficiently. > > > However, it has to be considered about the processing which > > > performed only when connection is established. This problem is > > > appeared in webrick/https. > > > > Second try. This time I select on @listeners and sockets in two seperate > > threads to avoid using @listeners.include?. Also, I removed the timeouts > > on the selects and used a pipe to notify the socket-listening thread when > > a socket is being returned to the main loop. > > If TCPSocket is wrapped by another class in run method, this patch > doesn't work well. In my https implementation, SSL session is > established and closed in HTTPServer#run (webrick/https.rb override > this). An instance of SSLSocket is managed by local variable on the > stack, so it cannot be referred again after run method returned. > > And, webrick/https is implemented without using start_hook(). It's > reserved for users and never used in builtin classes. For example, > access control with Seki's ACL can be written as follows. Hmm. Maybe this wasnt such a good idea afterall. The attached patch which is much simpler and changes less solves the same problem, starvation, but does it simply by launching new thread when needed. Futhermore, threads time out and exit after 10 seconds with nothing to do. (Patch is for snapshot version this time). -- Lars Christensen, larsch@cs.auc.dk82_2.txt (attatchment)(tag is disabled)