- From: Vic Bancroft <bancroft@america.net>
- Date: 09 Sep 2003 23:26:14 -0400
- To: "Jerry G. Chiuan" <jerry@oridus.com>
- Cc: www-lib@w3.org
On Tue, 2003-09-09 at 13:42, Jerry G. Chiuan wrote: > Since libwww internally only has one thread for sending requests, and I want > to have 2 threads in my application I had implemented a socket server based on the libwww server example, http://www.w3.org/Library/Examples/listen.c which had one thread to do the socket accept event loop. It is useful to look at the generic network functions in http://www.w3.org/Library/src/HTTCP.html That thread turned around and cloned the relevant structures such as http://www.w3.org/Library/src/HTNet.html and invoked another thread to handle that particular client request. The per client thread then resolved the request three different ways, local data, remote tcp connection and remote APPC connection. The remote APPC services were implemented by using defining a protocol module http://www.w3.org/Library/src/HTProt.html and it's associated application transport protocol, http://www.w3.org/Library/src/HTTrans.html When the request was enqueued (routed) to a particular remote server thread (one per remote host), the per client thread blocked on a mutex until the remote server returned or timed out. The request for a remote server was treated like a "normal" client use of the library, e.g., http://www.w3.org/Library/Examples/range.c Since the library is "good old c" anyone just needs to be careful to clone the data structures deep enough to avoid conflicts after handoff form one thread to another. The thread count was : one per port listener (1) , one per client request (n), and one per remote host (m). The libwww shared object part of this application was developed mainly under linux, ran comfortably under solaris and finally ported to NT4 all wrapped up as a service dll. . . . more, l8r, v
Received on Tuesday, 9 September 2003 23:08:55 UTC