W3C home > Mailing lists > Public > www-lib@w3.org > April to June 2002

RE: hanging in select() and using libwww from multithreaded apps

From: Osmond, Emily (Factiva) <Emily.Osmond@factiva.com>
Date: Fri, 10 May 2002 08:47:05 -0400
To: "'Kenneth B. Haase'" <haase@beingmeta.com>
Cc: "'www-lib@w3.org'" <www-lib@w3.org>
Message-ID: <B590D9176561D411BED000508BCF54180257D1A1@sbrmxsmb02.us.factiva.com>
Hi Kenneth,
I did not receive the attachment.  Can you please send it again.
Thank you very much.

-----Original Message-----
From: Kenneth B. Haase [mailto:haase@beingmeta.com]
Sent: Friday, May 10, 2002 8:32 AM
To: Osmond, Emily
Cc: 'www-lib@w3.org'
Subject: Re: hanging in select() and using libwww from multithreaded
apps


If your problem is the same one that I ran into, it is that the core
event loop determines the select() timeout based on the active tasks. 
If there aren't any active tasks, it never times out.  If this is the
case, the attached patch should fix that particular problem.

However, there is a larger problem of libwww not interacting well with
multi-threaded apps since the core library functions are not reentrant. 
So if two threads are calling the library at the same time, they might
damage some of libwww's internal state variables.  As long as this isn't
going to happen in your use of the library, the above patch should help.

More generally, I would be interested in writing some lightweight
reentrant wrappers to libwww or in working with others to do so.  I
expect that the general design would be to (a) provide locked access to
the library as a whole, where the core event loop locks the library and
(b) to provide a call out of the main event loop to allow other threads
to get a handle on this lock.

Any libwww experts see any problem with this approach?  Is there even
something out there (or in there) which already provides this
functionality?

-- Ken

On Wed, 2002-05-08 at 22:42, Osmond, Emily (Factiva) wrote:
> Hello,
> I'm using libwww in Tru64 Unix.  My application is multi-threaded.  One of
> the threads sends http Post requests to another server.  After so many
> requests, the thread that calls libwww hangs in select().  Below is the
> stack trace after the thread has been idle for about 2 hours:
>  -- SEE Thread 0xd
> 
> thread 0x11 stopped at>*[__usleep_thread, 0x3ff800f0838]        beq
r19,
> 0x3ff800f0850
> (dbx) where
> >  0 __usleep_thread(0x292, 0x1200a98d8, 0x3ff800ddba0, 0xa0db33cd67264,
> 0x3ff801553f4) [0x3ff800f0838]
>    1 __sleep(0x0, 0x1, 0x11fff7d50, 0x13cd67264, 0xffffffff00000002)
> [0x3ff80155438]
>    2 main(argc = 5, argv = 0x11fffeda8, envp = 0x11fffedd8)
> ["fastclip.c":985, 0x1200a9ccc]
> (dbx) tstack
> 
> Thread 0x5:
> >  0 __hstQueueUnblockAndTerminate(0x0, 0x24, 0x0, 0x200000000, 0x0)
> [0x3ff805b0b10]
>    1 __hstSaveUnblockContext(0x3ff805a6038, 0x3ffc01b1470, 0x3ff00000000,
> 0x3ffc01b1470, 0x3ff80588d50) [0x3ff80590224]
> 
> Thread 0x7:
> >  0 __nxm_thread_block(0x3ff80598b30, 0x140099880, 0x140099d40,
> 0x140099880, 0x3ff8059d624) [0x3ff805b0ea8]
>    1 (unknown)() [0x3ff8059d64c]
>    2 (unknown)() [0x3ff8059d04c]
>    3 __thdBase(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff805a5e1c]
> 
> Thread 0x9:
> >  0 __nxm_idle(0x3ff80599740, 0x1400c3d40, 0x1400c3880, 0x0, 0x0)
> [0x3ff805b0e28]
>    1 __vpIdle(0x3ff8059f7a0, 0x1400c3d40, 0x1400c3880, 0x3ffc01b5c60,
> 0x1400c19d8) [0x3ff805afaec]
>    2 (unknown)() [0x3ff8059f79c]
>    3 (unknown)() [0x3ff8059dc3c]
>    4 __thdBase(0x3ff80598c10, 0x1400c3d40, 0x3ff8059d924, 0x1400c3880,
0x0)
> [0x3ff805a5e1c]
> 
> Thread 0xb:
> More (n if no)?
> >  0 __nxm_idle(0x3ff80599000, 0x1400a9880, 0x3ff00000001, 0x1400a9880,
> 0x3ff8058d3e0) [0x3ff805b0e28]
>    1 __vpIdle(0x3ff8059f7a0, 0x1400a9d40, 0x1400a9880, 0x3ffc01b5c60,
> 0x1400a79d8) [0x3ff805afaec]
>    2 (unknown)() [0x3ff8059f79c]
>    3 (unknown)() [0x3ff8059dc3c]
>    4 __thdBase(0x0, 0x0, 0x1400a7eb8, 0x1400a9880, 0x0) [0x3ff805a5e1c]
> 
> Thread 0xd:
> >  0 __select(0x16, 0xffffffffa55f7e04, 0x1, 0x1, 0x0) [0x3ff800d5868]
>    1 HTEventList_loop(theRequest = 0x140de8600)
> ["../../../w3c-libwww-5.3.2/Library/src/HTEvtLst.c":725, 0x3000200fc7c]
>    2 http_dlv_thread__7dlvHttpXv(this = 0x1400ad460) ["dlvHttp.C":346,
> 0x1200ce6cc]
>    3 http_thread__XPv( = (nil))
> ["../../include/dlvHttp.H~alt~deccxx_105C5CEF":89, 0x1200a63f8]
>    4 __thdBase(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff805a5e1c]
> 
> Thread 0xf:
> >  0 __usleep_thread(0x3ff00000008, 0x3ffc00895a8, 0x3ff800ddba0,
> 0x125b13cd671f3, 0x3ff801553f4) [0x3ff800f0838]
>    1 __sleep(0x0, 0xb4, 0x42, 0x3cd671f3, 0x0) [0x3ff80155438]
>    2 threadFunc__XPv( = (nil)) ["prf_threadfunc.c":224, 0x1200ba75c]
>    3 __thdBase(0x0, 0x0, 0x0, 0x0, 0x0) [0x3ff805a5e1c]
> More (n if no)?
> 
> Thread 0x11:
> >  0 __usleep_thread(0x292, 0x1200a98d8, 0x3ff800ddba0, 0xa0db33cd67264,
> 0x3ff801553f4) [0x3ff800f0838]
>    1 __sleep(0x0, 0x1, 0x11fff7d50, 0x13cd67264, 0xffffffff00000002)
> [0x3ff80155438]
>    2 main(argc = 5, argv = 0x11fffeda8, envp = 0x11fffedd8)
> ["fastclip.c":985, 0x1200a9ccc]
> (dbx) 
> I set the EventTimeout to 120000  (2 minutes).
> 
> Any help will be appreciated.  
> Thank you very much.
> 
> 
> > Emily Osmond	  	        	      
>       Factiva, a Dow Jones & Reuters Company 
>       PO Box 300 Princeton, 
>         New Jersey 08543-0300 
> Phone: (609) 627-2412
> > E-mail: emily.osmond@factiva.com
> > 
> > 
> 
-- 
Ken Haase
kh@beingmeta.com
beingmeta, inc.
www.beingmeta.com
Received on Friday, 10 May 2002 08:47:58 GMT

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