From: Tim R. <ti...@pr...> - 2006-06-14 22:42:58
|
On Wed, 14 Jun 2006 11:48:25 +1000, Oliver Bock <ol...@g7...> wrote: >Unfortunately OS X does not include /proc and therefore FreeBSD probably >doesn't either. My impression is that /proc is a relatively recent >innovation. > Hardly! It's as old as the X window system. /proc first appeared in SVR4 in 1984. Solaris had it in version 2.5. OpenBSD has it. I'd be shocked if FreeBSD didn't, and I'm very surprised that OS/X doesn't. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Oliver B. <ol...@g7...> - 2006-06-15 00:58:12
|
Tim Roberts wrote: > On Wed, 14 Jun 2006 11:48:25 +1000, Oliver Bock <ol...@g7...> wrote: > > Hardly! It's as old as the X window system. /proc first appeared in > SVR4 in 1984. Solaris had it in version 2.5. OpenBSD has it. I'd be > shocked if FreeBSD didn't, and I'm very surprised that OS/X doesn't. > Plenty of weird stuff came out with SVR4. Sensible people (and their operating systems) shunned these innovations for the architectural purity of the original BSD mechanisms. Sadly Linux has ushered in the age of *nix populism, and now everybody wants everything. Oliver P.S. http://www.kernelthread.com/mac/apme/procfs/ explains a bit about why OS X doesn't have it. |
From: Leith P. <lei...@gm...> - 2006-06-15 01:39:59
|
FreeBSD only provides part of /proc when linux compat is enabled. On 6/15/06, Oliver Bock <ol...@g7...> wrote: > Tim Roberts wrote: > > On Wed, 14 Jun 2006 11:48:25 +1000, Oliver Bock <ol...@g7...> wrote: > > > > Hardly! It's as old as the X window system. /proc first appeared in > > SVR4 in 1984. Solaris had it in version 2.5. OpenBSD has it. I'd be > > shocked if FreeBSD didn't, and I'm very surprised that OS/X doesn't. > > > > Plenty of weird stuff came out with SVR4. Sensible people (and their > operating systems) shunned these innovations for the architectural > purity of the original BSD mechanisms. Sadly Linux has ushered in the > age of *nix populism, and now everybody wants everything. > > > Oliver > > > P.S. http://www.kernelthread.com/mac/apme/procfs/ explains a bit about > why OS X doesn't have it. > > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Randall R. <ra...@ra...> - 2006-06-15 00:50:36
|
On Jun 14, 2006, at 6:42 PM, Tim Roberts wrote: > On Wed, 14 Jun 2006 11:48:25 +1000, Oliver Bock <ol...@g7...> wrote: >> Unfortunately OS X does not include /proc and therefore FreeBSD >> probably >> doesn't either. My impression is that /proc is a relatively recent >> innovation. > > Hardly! It's as old as the X window system. /proc first appeared in > SVR4 in 1984. Solaris had it in version 2.5. OpenBSD has it. I'd be > shocked if FreeBSD didn't, and I'm very surprised that OS/X doesn't. OS X certainly doesn't, and I, also, thought it was just a linux thing. -- Randall Randall <ra...@ra...> "This is a fascinating question, right up there with whether rocks fall because of gravity or being dropped, and whether 3+5=5+3 because addition is commutative or because they both equal 8." - Scott Aaronson |
From: Oliver B. <ol...@g7...> - 2006-06-19 07:50:11
|
My system allows users to write their own python code fragments for some tasks. Unfortunately the users sometimes write infinite loops, which gradually lock up threads until none remain. A few minutes later a monitor notices that the system is unresponsive and kills and restarts AppServer. There must be a better way. 1. Can I find out how long each busy thread has been working on its current request? 2. Can I kill threads without irritating w4py? I guess I can roll my own solution for detecting busy threads, but I'm hoping someone else has a solution for this, or that I've failed to notice something obvious that already exists. Oliver |
From: Shayne O'N. <sh...@pe...> - 2006-06-19 09:49:14
|
Without wanting to be rude, but is there a point to the exercise? If this is a problem then one would presume that they can just restart the system if it locks and check out the stack dump? On Mon, 19 Jun 2006, Oliver Bock wrote: > My system allows users to write their own python code fragments for some > tasks. Unfortunately the users sometimes write infinite loops, which > gradually lock up threads until none remain. A few minutes later a > monitor notices that the system is unresponsive and kills and restarts > AppServer. There must be a better way. > > 1. Can I find out how long each busy thread has been working on its > current request? > 2. Can I kill threads without irritating w4py? > > I guess I can roll my own solution for detecting busy threads, but I'm > hoping someone else has a solution for this, or that I've failed to > notice something obvious that already exists. > > > Oliver > > > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Ian B. <ia...@co...> - 2006-06-21 00:08:49
|
Oliver Bock wrote: > My system allows users to write their own python code fragments for some > tasks. Unfortunately the users sometimes write infinite loops, which > gradually lock up threads until none remain. A few minutes later a > monitor notices that the system is unresponsive and kills and restarts > AppServer. There must be a better way. > > 1. Can I find out how long each busy thread has been working on its > current request? It's been a while since I've been in that code (ThreadedAppServer) but no, I don't believe there's a way to detect wedged threads. That would be a nice feature. > 2. Can I kill threads without irritating w4py? Back to basics: no, you can't kill threads in Python. You can only kill the entire process, and even then you have to kill -9 it if a thread is truly wedged. If you have tasks you really expect to sometimes wedge, you need to run them in a subprocess that is monitored. Unfortunately this is not that easy. But at least it *can* be done, the thread monitoring can't be done. Another perhaps more conservative option is to monitor for wedged threads, and then self-destruct the entire process when that happens. Using the reloader or something like supervisor (http://www.plope.com/software/supervisor) the process can come back up after being taken down. -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |
From: Oliver B. <ol...@g7...> - 2006-06-21 00:48:00
|
Ian Bicking wrote: > It's been a while since I've been in that code (ThreadedAppServer) but > no, I don't believe there's a way to detect wedged threads. That would > be a nice feature. How about this plan: as each thread starts a request we record the time processing begins in the thread object. This could be used in two ways: 1. An admin servlet could present the status of all threads. 2. An external process could monitor the status of threads via MonitorHandler. When it decides that the wedge factor is too great it issues SIGTERM to give non-wedged threads a chance to shutdown cleanly and then, after four seconds, sends SIGKILL. It then immediately restarts the process. I can't find any security in MonitorHandler. Is there any? What's to stop someone sending QUIT to my server? Oliver |