I don't mean to disparage other Ruby application servers, but this is why I use Passenger. It's not that I believe other Ruby application servers aren't good, or that their authors don't understand Unix as well as the guys at Phusion, but there's a real dedication to stability and predictability inside Phusion that I don't see elsewhere.
You can acheive the same results with other app servers, but you're going to have to do a lot of the heavy lifting yourself. I'm not ashamed to admit that I have a lot more confidence in Passenger's solution than I do my own.
I'm not sure if that's darwin terminology, but calling a process that's blocking on io or in a tight loop "frozen" certainly isn't tradition in UNIX - you're much more likely to use hung or stuck. In linux specifically the term has a completely different meaning - "freezing" a process is intentional and involves putting the process into a cgroup and then removing all cpu shares to prevent it from executing - suspending the process and allowing for sleep/hibernation/etc.
You do realize that it's quite easy to solve the halting problem in most cases, right?
The halting problem is unsolvable because _very particular_ (and pathological) cases are unsolvable. If a process is in a loop between the same instructions at the same states, it's very easy to tell that it's not going to halt -- the only challenge is that you can't make this determination for all processes all the time.
Mathematically, note that the concept of an oracle for the halting problem is well-defined (and a useful concept).
No. To instruct kill() to kill a process group, you have to specified the PID of the process group leader as a negative number. Otherwise kill() will kill only a single process.
19 comments
[ 3.5 ms ] story [ 56.0 ms ] threadYou can acheive the same results with other app servers, but you're going to have to do a lot of the heavy lifting yourself. I'm not ashamed to admit that I have a lot more confidence in Passenger's solution than I do my own.
The halting problem is unsolvable because _very particular_ (and pathological) cases are unsolvable. If a process is in a loop between the same instructions at the same states, it's very easy to tell that it's not going to halt -- the only challenge is that you can't make this determination for all processes all the time.
Mathematically, note that the concept of an oracle for the halting problem is well-defined (and a useful concept).
There are in fact fairly reliable heuristics for noting when things are going pear-shaped. The edge cases get sticky though.
Again, sorry for the noob question. I'm still learning and making mistakes.
Say the PGID I get for sh is 321. If I do
that will not kill all the processes having PGID 321?If it would not kill them, then couldn't we modify kill(1) to be able to call kill() with a negative integer as you describe?
Sorry for the noob questions. I am still learning and making mistakes.