W3C home > Mailing lists > Public > www-lib@w3.org > January to March 2001

Re: libwww multithreading once more...

From: Anton Belov -- Customer Engineering <antonb@scot.canada.sun.com>
Date: Wed, 28 Mar 2001 10:44:48 -0500 (EST)
Message-Id: <200103281544.KAA05722@rayo.canada.sun.com>
To: www-lib@w3.org
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 10:48:39 GMT

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