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

Fw: libwww multithreading once more...

From: Olga Antropova <olga@eai.com>
Date: Wed, 28 Mar 2001 09:32:18 -0600
Message-ID: <005001c0b79c$4673f6c0$3f05010a@eai.com>
To: <www-lib@w3.org>
 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
> >
> >
>
Received on Wednesday, 28 March 2001 10:30:41 GMT

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