Is there a way to determine what the thread is doing? I'm trying to troubleshoot some long running scripts here.
On Thursday 10 January 2002 03:15 pm, you wrote: > The problem is that even if you close the conn, the Tcl interp will go > on doing whatever it is doing... > > Can a thread be forcibly removed by pthread? :) If so, some thread could > do that via filters - a queue of what to remove from the system. The > problem would be the Tcl interp associated with a thread. > > I suppose it's nearly impossible to do on a thread-based platform. > > David Walker wrote: > > What about using Ns_ConnClose in a scheduled proc that runs every x > > minutes (or x/2 minutes) and closes conns that have exceeded their time > > limit? > > > > On Thursday 10 January 2002 12:51 pm, you wrote: > >>On Thursday, January 10, 2002, at 12:04 PM, Jim Wilcoxson wrote: > >>>It would be really cool if there were a way to set a CPU and/or real > >>>time limit for scripts from inside the script, and invoke a proc > >>>with args or something, like a signal handler. > >> > >>For hosting, I really wanted to be able to use the rlimit facilities to > >>limit CPU use, but the problem is that rlimit sets per-process limits, > >> and AOLserver is thread-based. What I usually want is to limit the CPU > >> time allowed per-response, but there's no OS-enforceable way to do this > >> without involving all the threads. Back when virtual hosting was part > >> of AOLserver, that would have been unacceptable. > >> > >>If using rlimit is acceptable for you, the "limit" command in some shells > >>can set a per-process CPU time limit, or you can write a wrapper for > >>AOLserver that calls rlimit before exec-ing AOLserver. > >> > >>In fact, rlimit will deliver a signal to the process when you exceed the > >>soft CPU limit, but it seems to me that you can only contract your CPU > >>limit, you can't expand it, so you couldn't set a recurring limit for > >>requests. > >> > >>Next operating system I write will have per-thread resource controls!
