> IMO, instead of killing processes, it would be better to keep the hanging
> behavior in place, but place limits on the resources used by a subsection
> of the process tree. Think ulimit, but applying to entire process heirarchies.
Once you introduce limits, you become responsible for applying th
> I have beeb writing codes believing those error return is working.
And so you should. Just because an error condition does not have a
clean resolution, does not mean it should not be reported. Or, for
that matter, that one should not be assisted in figuring out whether
an operation was success
Too complex to use, especially since processes come and go regularly.
IMO, instead of killing processes, it would be better to keep the hanging
behavior in place, but place limits on the resources used by a subsection
of the process tree. Think ulimit, but applying to entire process heirarchies.
Hello,
On 24 January 2015 at 20:48, erik quanstrom wrote:
> looks like a power even took out the motherboard. hopefully i can find
> some parts early next week.
>
> - erik
does that mean I can't download 9atom now?
(the web page www.9atom.org is up, but going to 386 iso
[ftp.9atom.org] doesn't
Hello,
> i think it will go the same way with fork protection. how do you tell which
> program
> is at fault? how do you tell a program forking at high frequency, with short
> lived
> children from a fork bomb? (such as a busy web server.)
only system administrator knows which processes shou
http://uriel.cat-v.org/quotes
--
С наилучшими пожеланиями
Жилкин Сергей
With best regards
Zhilkin Sergey
> many of resource exhaustion come from careless programming.
> I would like such processes to be killed immediately.
> throwing up to broken state might be better.
at the danger of repeating myself, the linux oom killer fills a similar role.
its job
is to try to identify the process that caused
> > many of resource exhaustion come from careless programming.
> > I would like such processes to be killed immediately.
> > throwing up to broken state might be better.
> > I prefer an option to plan9.ini that enable resrcwait(), because the call
> > breaks
> > traditional programming style and
On Jan 26, 2015, at 4:33 PM, arisawa wrote:
> many of resource exhaustion come from careless programming.
> I would like such processes to be killed immediately.
> throwing up to broken state might be better.
> I prefer an option to plan9.ini that enable resrcwait(), because the call
> breaks
>
Hello,
many of resource exhaustion come from careless programming.
I would like such processes to be killed immediately.
throwing up to broken state might be better.
I prefer an option to plan9.ini that enable resrcwait(), because the call breaks
traditional programming style and probably we need
On Mon Jan 26 03:43:36 PST 2015, aris...@ar.aichi-u.ac.jp wrote:
> Hello,
>
> I have been playing the following program.
> I tried on official plan9, 9front, and 9atom.
> none of them showed messages that come from:
> sysfatal("fork: %r”);
> sysfatal("exec: %r");
> I su
yes, look at newproc() in port/proc.c
the resrcwait() call in there is what erik was refering to
that makes rfork(RFPROC) sleep until a process gets available
instead of failing.
--
cinap
Hello,
I have been playing the following program.
I tried on official plan9, 9front, and 9atom.
none of them showed messages that come from:
sysfatal("fork: %r”);
sysfatal("exec: %r");
I suspect that
fork()
does not return -1 even if it failed in creating ne
13 matches
Mail list logo
