From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a6c65cbc407987fe X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-18 06:39:21 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!skates!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: dynamic multithreading Date: 18 Nov 2002 09:30:30 -0500 Organization: NASA Goddard Space Flight Center (skates.gsfc.nasa.gov) Message-ID: References: <3DD3D841.CD16A4CB@canal-plus.fr> <8MCB9.8643$8o1.1371873@news.xtra.co.nz> NNTP-Posting-Host: anarres.gsfc.nasa.gov Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: skates.gsfc.nasa.gov 1037630524 7719 128.183.235.92 (18 Nov 2002 14:42:04 GMT) X-Complaints-To: usenet@news.gsfc.nasa.gov NNTP-Posting-Date: 18 Nov 2002 14:42:04 GMT User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:31044 Date: 2002-11-18T14:42:04+00:00 List-Id: "AG" writes: > "Thierry Lelegard" wrote in message > news:3DD3D841.CD16A4CB@canal-plus.fr... > > - Second, you must absolutely unchecked_deallocate each task after > > it is terminated (not always trivial to synchronize on actual > > termination of a task). Otherwise, you have a memory leak. > > Which means you don't trust the run-time system to do some > elementary GC? Well, since the Ada Standard says that anything allocated with "new" will _not_ be "garbage collected", I do _not_ expect the "run-time system" to do "free" for me. Nothing wrong with doing "free" myself. If, as Thierry hinted, it is not easy to determine when the "free" is safe, then why would it be any easier for some run-time system to determine this? > If you are *that* paranoid (or have a good reason to be) perhaps > it's time to abandon Ada and switch back to the good old Assembly > language. Name one Assembly language that has garbage collection! Paranoia has nothing to do with it; this is about reading the standard and understanding what it says. > > As an alternative, never let a service task die. Once a task has > > finished servicing a connection, make it wait and reuse it for a > > later connection. > > Yuck. That means the task needs to be able to reset to a clean > state anytime it's finished with a connection. Yes. Why is that hard? If the state is not "clean", then there are loose ends that should be cleaned up. Why is it ok to "just kill" something with loose ends? That's a sloppy design. > It would also need to handle all possible error conditions and > abnormal ends to be able to come back on line "up and ready". It's > much much cleaner to just let the task die and start from scratch. Apparently you believe the operation of "let the task die" will clean up all the loose ends and restore a clean state. Can you quote the Ada Standard to justify that? How, exactly, do you "let the task die"? > (Hey, how many projects agonized like that for years instead of just > restarting at a good time?) Interesting analogy. > That does not include the safety-critical systems, of course, just > the common "run of the mill" things. If it makes money for me, it is _not_ "run of the mill" :). > > This is not so difficult to design and much more robust. > > I'd disagree. It is much easier to design a system which > always starts from scratch. That's arguable :). > There is also a lot less potential for errors since you don't need > to keep or handle previous states. You are assuming the operating system does it for you. Not a safe assumption. > So how can it be less robust? Knowing precisely what is going on is always more robust than hoping some undocumented feature will save you. > (Unless, as stated above, you simply don't trust your run-time > system to even de-allocate the stack) I don't trust the run-time system to do something it explicitly says it will _not_ do! -- -- Stephe