W3C home > Mailing lists > Public > www-lib@w3.org > October to December 2002

RE: using threads in libwww

From: <christophe.pierret@businessobjects.com>
Date: Thu, 10 Oct 2002 17:13:19 +0200
Message-ID: <DDF8255AC466D311A14B0008C7EBBCCB0A021537@exch-fra-lv03.businessobjects.com>
To: olga.antropova@eds.com, www-lib@w3.org

I have taken the second approach, but I have only done it for Windows, and
specialized for a server environment (ie: no message loop).
Basically, you have one HTTP worker thread that uses libwww to fulfill
requests posted by another thread (and stored in a 'synchronised' queue).
This approach may have better performance than the multi-threaded
"libwww-synchronised" solution.
I wrote a custom HTEvtLst.c for that purpose.

For windows sockets select and notification:
I used WSAEventSelect and WaitForMultipleObjects instead of the original
WSAAsyncSelect and GetMessage in event loop.
The shortcoming is that since you cannot have multiple threads running
libwww and you have a limit of 64 events you can wait for, you cannot have
more than 63 active requests (1 event is reserved for communication between
main thread and libwww event loop).
In a GUI environment, I would have used the MsgWaitForMultipleObjects ...

For unixes, I would have had to use a pipe to get out of the 'select' call,
in order to process new request 'post' from main thread, and I had no time
to write it under Unix.

My code for HTEvtLst/threaded under windows is available upon request.

I also had to remove limitations about HTHost and HTAnchor (in a server
environment, I call these limitations 'memleaks' :-)

Christophe


-----Original Message-----
From: Antropova, Olga A. [mailto:olga.antropova@eds.com]
Sent: mardi 8 octobre 2002 19:10
To: www-lib@w3.org
Cc: www-lib@w3.org
Subject: RE: using threads in libwww






In our product we are using libwww in multithreaded environment but we are
locking all libwww accesses so serializing those. The wwwlib is NOT thread
safe. That is the simplest approach to handle libwww in multithreaded
invironment.

Libww supports concurrent requests processing though. One can take advantage
of that starting the libwww in the separate thread and then communicating
the other threads requests to it. The library thread will be then processing
request in the concurrent facion and when processing of the request is
finised it would notify the threads waiting on the responses that the job is
done.

Thanks,
Olga.

-----Original Message-----
From: mnautiyal@hss.hns.com [mailto:mnautiyal@hss.hns.com]
Sent: Tuesday, October 08, 2002 10:57 AM
To: Daniel Stenberg
Cc: www-lib@w3.org
Subject: Re: using threads in libwww






Hi,

Is this possible in libwww, as we are also using libww for RDF parsing. So
we
can't get away with
this to new one right now.

So far I've about known from libww mailing lists that even in multithreading
the
requests have
to be serialized among the threads. Hence from a single multithreaded
application the effect
would not be better than as done in a single threaded (virtually no threads)
application.
But my problem is by creating a thread and posting data to server on this
thread
is not working.
why?

Thanks,
Manoj





Daniel Stenberg <daniel@haxx.se> on 10/08/2002 09:09:50 PM

To:   Manoj Nautiyal/HSS@HSS
cc:   www-lib@w3.org

Subject:  Re: using threads in libwww





On Tue, 8 Oct 2002 mnautiyal@hss.hns.com wrote:

> Please advise how can I get the post successful using thread?

I realize this is not strictly speaking an answer to your question, but for
most people this would be more easier done using libcurl
(http://curl.haxx.se/libcurl/), which also happens to be thread-safe and
requires less code for the same result.

libcurl does not offer a full libwww replacement. It is fairly lightweight
in
comparison.

Then again I'm biased, I'm the main author of libcurl.

I'll go back and hide again now.

--
      Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Received on Thursday, 10 October 2002 11:13:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:42 GMT