Re: dynamic multithreading

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

"AG" <ang@xtra.co.nz> writes:

> "Thierry Lelegard" <thierry.lelegard@canal-plus.fr> 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