W3C home > Mailing lists > Public > www-lib@w3.org > July to September 2003

init n + m + 1 libwww's

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
Message-Id: <1063164375.1941.131.camel@localhost.localdomain>

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,


which had one thread to do the socket accept event loop.  It is useful
to look at the generic network functions in


That thread turned around and cloned the relevant structures such as


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


and it's associated application transport protocol,


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.,


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.
. . . 

Received on Tuesday, 9 September 2003 23:08:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:56 UTC