Re: libwww multithreading once more...

We also used WinInet on PC and libwww on UNIX but we had a customized
wrapper around both.
Because of the single threaded nature of libwww we are designing own HTTP
client. That probably will be a stand alone application (server :-) written
in Java using HTTPClient class.
Olga.
----- Original Message -----
From: "Anton Belov -- Customer Engineering" <antonb@scot.canada.sun.com>
To: <www-lib@w3.org>
Sent: Wednesday, March 28, 2001 9:44 AM
Subject: Re: libwww multithreading once more...


> I think that the processing time may benefit from non-blocking sockets
> functionality, especially if requests go over a slow network (internet) -
a big
> chunk of the time will be spent on waiting for the response on the socket,
so if
> you use non-blocking ones you may be able to send out a few other requests
while
> waiting.
>
> On a fast network (intranet) it probably won't matter though ...
>
> On the same topic: what we've done here is to write a little wrapper
around
> libwww that exposes the exact same interface to the user as Microsoft's
WinInet
> DLL (that's why we needed to support multithreading), then we did a little
> performance comparison on a similar horse-power machines (one NT and
another
> Solaris). For single thread requests we beat them consistenly, the request
> processing time was at about 30% faster with libwww. However, when we
started to
> add more threads the signle-threaded nature of libwww showed it's face -
the
> response time was increasing linearly with coefficent of 1 with number of
> threads (10 threads, almost 10 times slower request time), whereas on NT
the
> increase was much slower (10 threads, 5 times slower request time). It was
good
> enough for us, but still it's too bad, because the potential is obviously
there.
>
>
> Cheers,
> Anton
>
>
> >X-Authentication-Warning: balefire.eai.com: uucp set sender to
<olga@eai.com>
> using -f
> >Really-From: olga@eai.com
> >From: "Olga Antropova" <olga@eai.com>
> >To: "Anton Belov -- Customer Engineering"
<antonb@opcom-mail.canada.sun.com>
> >Subject: Re: libwww multithreading once more...
> >Date: Wed, 28 Mar 2001 09:20:13 -0600
> >MIME-Version: 1.0
> >Content-Transfer-Encoding: 7bit
> >X-Priority: 3
> >X-MSMail-Priority: Normal
> >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
> >
> >Yes,
> >Mutexes will serialize the requests making non-bloking functionality
> >useless. That is if you lock mutex in event (request) registering and
unlock
> >it in request-done callback.
> >Common processing time will be the same but the responsiveness from the
> >clients point of view would suffer.
> >Olga.
> >
> >----- Original Message -----
> >From: "Anton Belov -- Customer Engineering" <antonb@scot.canada.sun.com>
> >To: <olga@eai.com>
> >Sent: Tuesday, March 27, 2001 10:36 AM
> >Subject: Re: libwww multithreading once more...
> >
> >
> >> Wouldn't it make harder to make use of non-blocking sockets
functionality
> >?
> >>
> >>
> >>
> >>
> >> >X-Authentication-Warning: balefire.eai.com: uucp set sender to
> ><olga@eai.com>
> >> using -f
> >> >Really-From: olga@eai.com
> >> >From: "Olga Antropova" <olga@eai.com>
> >> >To: "Anton Belov -- Customer Engineering"
> ><antonb@opcom-mail.canada.sun.com>,
> >> <www-lib@w3.org>
> >> >Subject: Re: libwww multithreading once more...
> >> >Date: Tue, 27 Mar 2001 10:37:30 -0600
> >> >MIME-Version: 1.0
> >> >Content-Transfer-Encoding: 7bit
> >> >X-Priority: 3
> >> >X-MSMail-Priority: Normal
> >> >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
> >> >
> >> >Yes,
> >> >I have simulated multithread-safe libwww having mutexes around the top
> >level
> >> >lib accesses in a little lib wrapper.
> >> >That is simpler and achives (close to) the same behavior.
> >> >
> >> >Olga.
> >> >
> >> >----- Original Message -----
> >> >From: "Anton Belov -- Customer Engineering"
<antonb@scot.canada.sun.com>
> >> >To: <www-lib@w3.org>
> >> >Sent: Tuesday, March 27, 2001 10:07 AM
> >> >Subject: Re: libwww multithreading once more...
> >> >
> >> >
> >> >> We have simulated the multithread-safe behaviour, by having only one
> >> >thread
> >> >> sitting in the event loop, and others coming in and notifying it
> >(through
> >> >domain
> >> >> socket) that they want to send a request. The event-loop thread
would
> >go
> >> >and
> >> >> pick up the request details and send it out, in a mean while the
> >requester
> >> >> thread will sleep (on condition variable) until it's notified by the
> >> >event-loop
> >> >> thread that it finished processing the request.
> >> >>
> >> >> This way the access to the library is always within the same one
> >thread,
> >> >on the
> >> >> other hand an application that uses it thinks that it's doing
> >> >mutlithreaded
> >> >> access. Of course, performance-wise it makes absolutely no
difference,
> >> >since the
> >> >> access is serialized.
> >> >>
> >> >> Cheers,
> >> >> Anton
> >> >>
> >> >>
> >> >> >Resent-Date: Tue, 27 Mar 2001 10:39:47 -0500 (EST)
> >> >> >Resent-Message-Id: <200103271539.KAA04774@www19.w3.org>
> >> >> >X-Authentication-Warning: balefire.eai.com: uucp set sender to
> >> ><olga@eai.com>
> >> >> using -f
> >> >> >Really-From: olga@eai.com
> >> >> >From: "Olga Antropova" <olga@eai.com>
> >> >> >To: "Roland Bickel" <r.bickel@cmg.nl>, <www-lib@w3.org>
> >> >> >Date: Tue, 27 Mar 2001 09:40:01 -0600
> >> >> >MIME-Version: 1.0
> >> >> >Content-Transfer-Encoding: 7bit
> >> >> >X-Priority: 3
> >> >> >X-MSMail-Priority: Normal
> >> >> >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
> >> >> >Subject: Re: libwww multithreading once more...
> >> >> >Resent-From: www-lib@w3.org
> >> >> >X-Mailing-List: <www-lib@w3.org> archive/latest/4813
> >> >> >X-Loop: www-lib@w3.org
> >> >> >Resent-Sender: www-lib-request@w3.org
> >> >> >List-Id: <www-lib.w3.org>
> >> >> >List-Help: <http://www.w3.org/Mail/>
> >> >> >List-Unsubscribe:
<mailto:www-lib-request@w3.org?subject=unsubscribe>
> >> >> >
> >> >> >Hi,
> >> >> >
> >> >> >In general there are two ways to do multiple requests processing at
> >the
> >> >same
> >> >> >time:
> >> >> >
> >> >> >1) blocking system calls and threads
> >> >> >2) non-blocking system calls and a sophisticated state machine
> >> >> >
> >> >> >On the single processor computer the performance of this two
> >approaches
> >> >> >should be about the same.
> >> >> >
> >> >> >libwww implements the second way of mutiprocessing. That is a more
> >> >complex
> >> >> >of the two approaches.
> >> >> >Laying threads on top of this approach is way too complex if not
> >> >impossible.
> >> >> >
> >> >> >I personally think that libwww is impossible to make thread safe.
> >There
> >> >are
> >> >> >too many global structures.
> >> >> >
> >> >> >Olga.
> >> >> >
> >> >> >----- Original Message -----
> >> >> >From: "Roland Bickel" <r.bickel@cmg.nl>
> >> >> >To: <www-lib@w3.org>
> >> >> >Sent: Tuesday, March 27, 2001 9:21 AM
> >> >> >Subject: libwww multithreading once more...
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> Right, i've spent a lot of time trying to figure out how the
> >following
> >> >> >could
> >> >> >> be implemented in a asynchronous way.. I hope some of you
guys/girls
> >> >can
> >> >> >be
> >> >> >> of help... i cannot imagine i'm the only one ever stumbling
across
> >this
> >> >> >> problem ...
> >> >> >>
> >> >> >> here goes :
> >> >> >> i want to be able to do multiple, simultaneous http PUT messages,
> >> >> >> preferrably without a fork construct. So suppose i have one
thread
> >> >walking
> >> >> >> through the even loop waiting for responses to a previous issued
PUT
> >,
> >> >if
> >> >> >> another process tries to send another PUT message *how* can I
update
> >> >the
> >> >> >> eventloop ? prefer some .c examples..
> >> >> >>
> >> >> >> Thanks in advance,
> >> >> >> Roland
> >> >> >>
> >> >> >> btw.. isn't there some FAQ ? i think this would make a nice
topic...
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
~v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^vv^v^v^v^v^v^v^v^v^v^v^~
> >> >>
> >> >> Anton Belov
> >> >> Sun Microsystems Americas Customer Engineering
> >> >> anton.belov@canada.sun.com
> >> >> Ph. (905)415-2841  Fax. (905)477-0217
> >> >>
> >> >>
> >> >
> >>
> >> ~v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^vv^v^v^v^v^v^v^v^v^v^v^~
> >>
> >> Anton Belov
> >> Sun Microsystems Americas Customer Engineering
> >> anton.belov@canada.sun.com
> >> Ph. (905)415-2841  Fax. (905)477-0217
> >>
> >>
> >
>
> ~v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^vv^v^v^v^v^v^v^v^v^v^v^~
>
> Anton Belov
> Sun Microsystems Americas Customer Engineering
> anton.belov@canada.sun.com
> Ph. (905)415-2841  Fax. (905)477-0217
>
>
> ------------- End Forwarded Message -------------
>
>
> ~v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^vv^v^v^v^v^v^v^v^v^v^v^~
>
> Anton Belov
> Sun Microsystems Americas Customer Engineering
> anton.belov@canada.sun.com
> Ph. (905)415-2841  Fax. (905)477-0217
>
>

Received on Wednesday, 28 March 2001 11:31:47 UTC