From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Prologue and epilogue aspects
Date: Thu, 1 Feb 2018 17:47:32 -0600
Date: 2018-02-01T17:47:32-06:00 [thread overview]
Message-ID: <p508uk$nl8$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: p4ul5c$582$1@gioia.aioe.org
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:p4ul5c$582$1@gioia.aioe.org...
> On 01/02/2018 01:17, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:p4sm09$126n$1@gioia.aioe.org...
>>> On 30/01/2018 23:02, Randy Brukardt wrote:
>> ...
>>>> Huh? If there is no implicit finalization, then there is no need for
>>>> controlled types at all, as they serve no purpose. (If you want to
>>>> explicitly finalize things, you can define any subprogram for that
>>>> purpose.
>>>
>>> "Implicit" meant called upon implicit destruction, e.g. when access
>>> types
>>> go out of the scope. That thing is not needed. I don't see other reason
>>> for the Controlled_Interface to induce hidden components.
>>
>> (1) Subpools and mutable types also need lists of some sort to properly
>> do
>> finalization.
>
> No, they need not. The rule would be that all explicitly allocated objects
> of Controlled_Interface must be explicitly deallocated.
Yes, but you need a list to explicitly deallocate a subpool (as there are
many objects in the subpool). Or you could just ban the use of subpools, but
that's madness.
>> (2) The reason for the "out of scope" rules is so that Finalization can
>> be
>> used for resource allocation beyond simply memory management. For
>> instance,
>> to return device (handles) to the OS when they won't be used any more. We
>> felt that there shouldn't be any leaks in that.
>
> I don't see how the feature would help. The only practical case when it
> takes effect is when exiting from the program. At that point it does not
> matter anyway.
It does if the underlying manager is primitive (as some RTOSes are) and
there is no automatic closing of handles. (That was the case on CP/M and
early MS-DOS, if one left files open when a program exited, they never got
closed at all. Which could lead to data loss or resource exhaustion.)
>> (3) I think you would have to ban nested access types (that can go out of
>> scope before program end) that designate type with parts of this kind of
>> controlled type, lest the allocation of such objects lead to guarenteed
>> storage leaks (one doesn't want to use Unchecked_Deallocation if they
>> don't
>> have to).
>
> Of course I would let them leak. No implicit deallocation.
OK, but that's not the way Ada handles types with Storage_Size specified.
I'd rather they were illegal (most of the accessibility madness comes from
allowing such types, and they're nearly useless).
>> (4) Chains for all controlled objects work best with exception handling,
>> as
>> it isn't necessary to enter every scope to try to clean up objects, and
>> in
>> particular, one doesn't have to deal with the horror of partially
>> initialized objects (whose initialization was interrupted by an
>> exception).
>
> It is always a controlled object that goes out the scope. All dynamically
> allocated controlled objects are in some kind of controlled container or
> other controlled structure responsible to deallocate them. Everything
> ultimately hooked on some scoped controlled object. That is the only sane
> design, IMO.
>
>> To use your static implementation, you also have to use a static
>> implementation of exceptions, and somehow keep track of initialization of
>> objects (and every part of such objects) in each scope.
>
> Then the scope can maintain a list of objects it initialized. I see no
> need to corrupt the object representation with list pointers in order to
> merely roll back the stack.
That's what I called "fiendishly complex". Sure, it can be done, but you
have to have a handler in every master with none trivial objects (regardless
of whether there is any explicit exception handlers, of even if there can
be). With the exception handing in our compiler, that would be a horrible
drag on performance even if no handlers were used (state snapshots would be
needed for each implicit handler, and handlers block optimizations as well,
so a lot of unneeded checks wouldn't be identified).
The only practical way to that is similar to the way that AdaCore does that
(for both finalization and exception handling), which would be a 2-3 man
year effort for any compiler vendor that isn't already using that scheme (so
far as I know, that's most of the non-AdaCore vendors).
And I doubt that even the AdaCore scheme quite matches to your goals. Plus
the lack of safety (there now are many ways to get skip finalization on
objects), I don't see anyone being very interested. It makes more sense,
honestly, to support full multiple inheritance.
Randy.
next prev parent reply other threads:[~2018-02-01 23:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-26 19:56 Prologue and epilogue aspects Dmitry A. Kazakov
2018-01-27 7:17 ` Randy Brukardt
2018-01-27 9:33 ` Dmitry A. Kazakov
2018-01-29 23:08 ` Randy Brukardt
2018-01-30 8:31 ` Dmitry A. Kazakov
2018-01-30 22:02 ` Randy Brukardt
2018-01-31 15:05 ` Dmitry A. Kazakov
2018-02-01 0:17 ` Randy Brukardt
2018-02-01 9:03 ` Dmitry A. Kazakov
2018-02-01 23:47 ` Randy Brukardt [this message]
2018-02-02 6:59 ` Niklas Holsti
2018-02-02 22:20 ` Randy Brukardt
2018-02-02 8:46 ` Dmitry A. Kazakov
2018-02-02 9:31 ` Niklas Holsti
2018-02-02 10:21 ` Dmitry A. Kazakov
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox