- 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>
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 UTC