From kragen@dnaco.net Tue Sep 15 13:15:55 1998 Date: Tue, 15 Sep 1998 13:15:53 -0400 (EDT) From: Kragen To: Alexander Kjeldaas cc: david@kalifornia.com, security-audit@ferret.lmh.ox.ac.uk Subject: Re: identd's In-Reply-To: <19980915130824.07477@lucifer.guardian.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Keywords: X-UID: 1998 Status: O X-Status: On Tue, 15 Sep 1998, Alexander Kjeldaas wrote: > I agree in part with Kragen. There is a small part of an interpreter > that you need to be sure of the correctness of. The rest of the > interpreter is mostly library stuff similar to the C-library. The > only problem I have with interpreters is real-time performance and > bounds on resource usage. If you write your C-programs carefully, you > can set an upper bound on the daemon's resource usage. This is true. But most C programs aren't written that way. Use of malloc() introduces unpredictable delays, for example. > Often you > don't have that option in an interpreted language and you have to take > into consideration DoS-attacks on the garbage-collector. Well, you have to take certain precautions against DoSes whatever language you program in. In C without dynamic allocation, you just put all kinds of arbitrary limits on sizes of things. In C with dynamic allocation, you have to put the same arbitrary limits to avoid DoSes. In interpreted languages with garbage collection, you have to do the same, and that also avoids the usual DoS problems with the garbage collector itself. (I might be understanding you incorrectly. Did you mean what I thought you meant -- that you can make the program create lots of small objects and thereby take up lots of CPU time in the gc?) > This is a > problem and for a daemon you should therefore use an implementation > that has been designed to run for a long time. My experience with > perl is that it is not suitable for a long-living process. The > garbage-collector in perl isn't good enough. You mean, it leaks? It's true that both Perl and Python use reference-counted garbage collection, which is prone to leakage of cyclic data structures. (They'd probably be much faster if they used ordinary garbage collection!) It is generally pretty easy to avoid creating cyclic data structures, though, to pander to the weaknesses of the implementations. > Some other systems such as Smalltalk or LISP are used to implement > long-running systems and I would trust their GC to be more robust. I > think both Sun's JDK and IBM's VisualAge uses the Great Circle garbage > collector which is pretty solid. FWIW, the Great Circle collector is a modified version of the free Boehm-Demers-Weiser collector. I believe that most of what Geodesic has added is improvements to the reporting, to aid in the use of Great Circle to find memory leaks in traditional programs that use explicit memory management. (Credibility note: I have never implemented a garbage collector, never written a program in Python, never written a program bigger than 1000 lines in Perl, never used the Boehm-Demers-Weiser collector, never used Great Circle, never written a widely-used or complex network daemon, never done real-time programming, and never launched or fixed a DoS attack. So take this message with a grain of salt.) Kragen (relaying what he's read) -- Kragen Sitaker The sages do not believe that making no mistakes is a blessing. They believe, rather, that the great virtue of man lies in his ability to correct his mistakes and continually make a new man of himself. -- Wang Yang-Ming