- From: Anton Belov -- Customer Engineering <antonb@scot.canada.sun.com>
- Date: Wed, 28 Mar 2001 10:44:48 -0500 (EST)
- 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 UTC