RE: multithred features in libwww

Gorton:

Libwww is not per se multi-threaded, but instead relies on a queueing
paradigm.  I implemented
a libwww app by creating a 'server' thread that pulls requests off of an
application queue,
runs the request in the server thread and places pointers to result data in
an out queue.

The performance using this approach is excellent.  You need to get familiar
with htevtlst.c to
understand how the thing actually works.  I'd also recommend single stepping
some of the
examples.  I've not done a *IX port but the code appears to work
approximately the same way
in *IX.

FYI, when I first started using libwww I thought 'what a kludge', but after
getting down into
the guts of the thing I like the approach.  On todays processors a single
CPU can usually bury
the pipe the box is hooked up to, so having a single thread do the network
work does not
appear to be a limitation.  In addition, because the core engine is single
threaded you get
to ignore most concurrency issues (like locking list structures) which
results in fewer
bugs in the network layer of the application (an area traditionally harder
to troubleshoot).

Just my 2 cents, anyone please correct me where I am wrong on this.

Regards,


Fred Covely
BCF Technology
fcovely@bcftech.com
(B)760-631-8157
(C)760-717-9689

-----Original Message-----
From: www-lib-request@w3.org [mailto:www-lib-request@w3.org]On Behalf Of
Gorton Zhao
Sent: Thursday, August 16, 2001 3:45 AM
To: henrikn@microsoft.com; www-lib@w3.org
Subject: Re: multithred features in libwww


My name is Gorton Zhao and I am working on a project that uses libwww. I
have tried to use it in a multi-threads environment and it does not seem to
work with multi-threads. Does anyone have any ideas about libwww in a
multithread environment. I would appreciate any helps on this.

Sincerely,
Gorton Zhao

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Received on Thursday, 16 August 2001 12:43:10 UTC