Re: If not Ada, what else...

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 29 Jul 2015 23:47:41 -0700, Paul Rubin wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> Since queues marshal data there is no place for GC here. You put a *copy*
> 
> Oh I see, I didn't realize that.  In Python you'd only be passing references.
> 
>> Queueing references (I do it all the time implementing drivers and
>> protocols) is a great pain and GC is no help, because of canceling
>> requests and other sorts of stuff requiring deterministic time and
>> order of execution such actions.  GC (at least a built-in one) has no
>> place in systems programming.
> 
> GC makes it simple, at the cost of deterministic timing.  I can
> understand why you might not want that in an Ada program.  I don't see
> how it affects ordering.

Because a reference does not enforce any specific order it only throws some
constraints in. If you wanted to use GC you would have to stuff things with
"hard" and "soft" references to ensure, for example, a proper order of
finalization (of interdependent things like driver, connection, I/O
request, variable).

"Soft" and "hard" references quickly become an utter mess without any
decent means to test it, e.g. that the mandated order is indeed enforced in
all cases. How do you test that? How could you prove anything about it? How
do you maintain software changes when you know nothing about the effects of
adding/removing a reference?

Furthermore, maintaining these references requires memory and other
containers to stuff them into. It is frequently 1-n relationships, thus you
have to keep a whole list of "soft" and/or "hard" references in an object.
Soft references require a lot of cycles to keep them updated, these cycles
are all synchronous walking-through lists and doing callbacks. Imagine that
in an interrupt routine! Worse, it is not a bounded time, there is no limit
on the number of "soft" references. Even worse it is not task-safe, you
will need interlocking on top of that huge pile of mess. You will get nice
deadlocks if not more complicated interlocking is used, an interlocking
that would require even more CPU cycles and even more context switches. And
priority inversions would be your least concern.

It is great to have things non-deterministic when dealing with system
resources, which are all singletons! When will the GC free a resource bound
to a to-be-collected object (e.g. a communication port)? How do you wait
for this, where do you wait for this?

And why all that? Because somebody was too lazy to think the design
through?

> Think of the Lisp machine.

Better not, I want to sleep at night... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de