2009/4/16 erik quanstrom <quans...@quanstro.net>: > have you taken a look at the protection measures already > built into the kernel like smalloc?
At least in FreeBSD, you can't sleep in an interrupt thread. I suppose that's probably also the case in Plan 9 interrupt handlers, and this would mitigate that situation. >> While it may not be perfectly ideal, it allows the administrator to >> maintain control over the system. > > being a system adminstrator, i dislike any ideas that require > extra adminstration. for the same reason, content-based email > filters are impossible to maintain yourself. you can't keep up > with the threats. There is that sentiment as well. I'm writing the code anyway, because at least the API implementation is smaller than the amount of text in emails I've already written about it (not to mention IRC discussion). I tend to feel like there should be reasonably large defaults so that you don't have to muck with it. Or maybe it's turned off by default. I don't know. Either way, I'm not particularly expecting it to be accepted as a patch, but I'm willing to be pleasantly surprised. Besides, I haven't touched my sources tree for a good two years. It needs something fresh :). > otoh, if you panic because you run out of resources or whatever, the > consequence should be a reboot. at most you loose some editor > state and need to spend a few minutes logging back in. Depends again on the application. If you're talking about a terminal, yes. If you're talking about a CPU server where someone is working on code, someone else is writing a presentation, and yet another person is in the middle of a video transcode, you're talking about a lot of wasted time, potentially. > if you allow users to log into your fileserver, you're asking > for trouble. Fileserver, I agree. I don't think a sane person would allow `untrusted' user access, let alone anonymous access.. On a CPU server, you kind of have to allow access to potentially untrusted users. That's kind of the definition. (Hell, even paying users aren't necessarily trustworthy. Tons of web hosts get exploited each year by paying customers). > the one resource that does need some fancier managment is > procs. the problem is that out-of-processes tends to act like > livelock. it would probablly be an improvement to set > ooprocs variable when out of procs and clear it when some > fraction (say 1/10) becomes free. then one could panic if > the out-of-processes condition persists for, say, 30 seconds. Maybe I'll look at that after this. > (i haven't had this problem since i added some better spam > filtering.) > > - erik Thanks for your insight so far, in any case :) --dho
