Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Does memory leak? (1995)

groups.google.com

Post reply on HN
Print view View original

41–50 of 289 posts

Re: Does memory leak? (1995)

#41

Post by rgacote »

chapium wrote: post #16
mojuba wrote: post #8

One other class of applications that don't really require garbage collection is HTTP request handlers if run as isolated processes. They are usually very short-lived - they can't even live longer than some maximum enforced by the server. For example, PHP takes advantage of this and allows you not to worry about circular references much.

This is clearly not my subject area. Why would we be spawning processes for HTTP requests? This sounds awful for performance. My best guess is a security guarantee.

The (web) world used to be synchronous. Traditional Apache spawns a number of threads and then keeps each thread around for x number or requests, after which the thread is killed and a new one spawned. Incredibly useful feature when you're on limited hardware and want to ensure you don't memory leak yourself out of existence. Modern Apache has newer options (and of course nginx has traditionally been entirely async on multiple threads).

Re: Does memory leak? (1995)

#42

Post by GordonS »

A bit OT, but I wonder how I'd feel if I was offered a job working on software for missiles.

I'm sure the technical challenge would be immensely interesting, and I could tell myself that I cared more about accuracy and correctness than other potential hires... but from a moral standpoint, I don't think I could bring myself to do it.

I realise of course that the military uses all sorts of software, including line of business apps, and indeed several military organisations use the B2B security software that my microISV sells, but I think it's very different to directly working on software for killing machines.

Re: Does memory leak? (1995)

#43

Post by thaumasiotes »

eru wrote: post #11
gameswithgo wrote: post #9

Earlier quoted context omitted.

If all software is built to protect against all possible future anticipated use cases, your software will take longer to make, perform worse, and be more likely to have bugs. If all software is built only to solve the problem at hand, it will take less time to develop, be less likely to have bugs, and perform better. It isn't clear that coding for reuse is going to get you a net win, especially since computing platfo…

There's a middle ground. Eg the classic Unix 'cat' (ignoring all the command line switches) does something really simple and re-usable, so it makes sense to make sure it does the Right Thing in all situations.

I mean, 'cat' does something so simple (apply the identity function to the input) that it has no need to be reusable because there's no point using it in the first place. If you have input, processing it with cat just means you wasted your time to produce something you already had.

Re: Does memory leak? (1995)

#45

Post by tyingq »

chapium wrote: post #16
mojuba wrote: post #8

One other class of applications that don't really require garbage collection is HTTP request handlers if run as isolated processes. They are usually very short-lived - they can't even live longer than some maximum enforced by the server. For example, PHP takes advantage of this and allows you not to worry about circular references much.

This is clearly not my subject area. Why would we be spawning processes for HTTP requests? This sounds awful for performance. My best guess is a security guarantee.

PHP these days doesn't fork and spawn a new process, though it does create a new interpreter context.

In the old cgi-bin days, every web request would fork and exec a new script, whether PHP, Perl, C program, etc. That was replaced with Apache modules (or nsapi, etc), then later, with long running process pooled frameworks like fcgi, php-fpm, etc. Perl and PHP typically then didn't fork for every request. But did create a fresh interpreter context to be backward compatible, avoid memory leaks, etc. So there's still overhead, but not as heavy as fork/exec.

Re: Does memory leak? (1995)

#46

Post by wbhart »

Missiles don't always hit their intended target. They can go off course, potentially be hacked, fall into the wrong hands, be sold to mass murderers, fail to explode, accidentally fall out of planes (even nuclear bombs have historically done this), miss their targets, encounter countermeasures, etc.

Nobody is claiming that this was done for reasons of good software design. It's perfectly reasonable to suspect it was done for reasons of cost or plain negligence.

There's a reason tech workers protest involvement of their firms with the military. It's because all too often arms are not used as a deterrent or as a means of absolute last resort, but because they are used due to faulty intelligence, public or political pressure, as a means of aggression, without regard to collateral damage or otherwise in a careless way.

The whole point here is the blase way the technician responded, "of course it leaks". The justification given is not that it was necessary for the design, but that it doesn't matter because it's going to explode at the end of its journey!

Re: Does memory leak? (1995)

#48

Post by blattimwind »

Out_of_Characte wrote: post #37

What an interesting concept. Good programmers always consider certain behaviours to be wrong. Memory 'leaks' being one of them. But this real application of purposefully not managing memory is also an interesting thought exercise. However counter intuitive, a memory leak in this case might be the most optimal solution in this problem space. I just never thought I would have to think of an object's lifetime in such a…

Cleaning up memory is an antipattern for many tools, especially of the EVA/IPO model (input-process-output). For example, cp(1) in preserve hard links mode has to keep track of things in a table; cleaning it up at the end of the operation is a waste of time. Someone "fixed" the leak to make valgrind happy and by doing so introduced a performance regression. Another example might be a compiler; it's pointless to deallocate all your structures manually before calling exit(). The kernel throwing away your address space is infinitely faster than you chasing every pointer you ever created down and then having the kernel throw away your address space. The situation is quite different of course if you are libcompiler.

Re: Does memory leak? (1995)

#49

Post by gameswithgo »

eru wrote: post #11
gameswithgo wrote: post #9

Earlier quoted context omitted.

If all software is built to protect against all possible future anticipated use cases, your software will take longer to make, perform worse, and be more likely to have bugs. If all software is built only to solve the problem at hand, it will take less time to develop, be less likely to have bugs, and perform better. It isn't clear that coding for reuse is going to get you a net win, especially since computing platfo…

There's a middle ground. Eg the classic Unix 'cat' (ignoring all the command line switches) does something really simple and re-usable, so it makes sense to make sure it does the Right Thing in all situations.

For sure, if you can apply a small amount of effort for a high probability of easy re-usability, do it. But if you start going off into weird abstract design land to solve a problem you don't have yet, while it might be fun, probably you should stop. At least if it is a real production thing you are working on.

Re: Does memory leak? (1995)

#50

Post by emsy »

Out_of_Characte wrote: post #37

What an interesting concept. Good programmers always consider certain behaviours to be wrong. Memory 'leaks' being one of them. But this real application of purposefully not managing memory is also an interesting thought exercise. However counter intuitive, a memory leak in this case might be the most optimal solution in this problem space. I just never thought I would have to think of an object's lifetime in such a…

No, they did what good engineers do: They analyzed the problem and found a feasible and robust solution. Following rules without thinking is not what good programmers do. I’d argue that most problems of modern software development stem from this mindset, even when it’s a rule that should be applied 99% of the time.
Post reply on HN