Re: Custom Storage Pool questions

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

On 2021-10-16 00:44, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:skbdb5$u50$1@gioia.aioe.org...
>> On 2021-10-15 02:36, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 

> In the case you describe, you'd have a binding that abstracts the
> two underlying libraries, and you'd unit test that. Assuming it
> passes with both implementations, it shouldn't matter which is used
> in a particular program.

You need to test switching between implementations. In the case of 
static linking that part is not even code and thus non-testable. You 
must test each concrete assembly of components each time and each 
assembly with have alternating code. Why do you think people keep on 
asking for Ada preprocessor in c.l.a?

>> Yes, but it is not economically viable anymore. Nobody would pay 
>> for that.
> 
> Has software gotten so 
> bad that no one cares about that?

Yes, and worse.

> I certainly would never do that to
>  our customers (and I hate support anyway, I want to reduce it as
> much as possible).

Compilers are not ware anymore. We live in a post-market era with 
neo-feudal economic relationships.

> There's no plug-ins in a statically linked system. What would be the
> point? I'm assuming that we're talking about Ada interfaced
> libraries here (C is a different kettle of fish), so you're talking
> about switching implementations of a single Ada spec. We've done that
> going back to the beginning of Ada time; it's managed by decent build
> tools and has gotten pretty simple in most Ada compilers. So what
> would a plug-in buy?

Yes, that is about build tools to develop and maintain, because 
dependencies handling and adjusting the code invoking optional 
components is specific to the problem domain. Such stuff does exist, 
e.g. this is how VxWorks or Yokto Linux images are configured. No way 
regular software could go this way.

>>> I don't see any way that such loading could work with Ada 
>>> semantics; there is an assumption that all of your ancestors 
>>> exist before you can do anything. The elaboration checks were 
>>> intended to check that.
>> 
>> We have a core libraries which are import libraries for the 
>> plug-in. When a plug-in is loaded, the core libraries are 
>> elaborated unless already loaded, the plug-in library itself is not
>> elaborated, because automatic elaboration would deadlock under 
>> Windows. Then a dedicated entry point is called in the plug-in 
>> library. The first thing it does is a call to the plug-in 
>> elaboration code. GNAT generates an <library-name>init entry for 
>> that. After this the plug-in registers itself providing a tagged 
>> object, which primitive operations are basically the library's true
>> interface.
>> 
>> I know it sounds horrific, but it works pretty well.
> 
> It does sound horrific, and it doesn't seem to buy much.

We started with a monolithic solution and were forced to redesign it 
when it became unmaintainable. Apart from the the fact that it bluntly 
refused to fit in 256K RAM of a target platform ...

> A tag is a property of a type in Ada, and it includes the dispatch 
> table.

No, it is just one possible implementation. It has a disadvantage that 
you must search a global map tag->vptr and you must keep the whole table 
per each tagged type. I suppose one could exchange the map tag->ptr with 
ptr->tag. Then dispatching will be cheaper and X'Tag more expensive. In 
any case you must adjust either map when elaborating the library.

> You can't unload a library until all of the things that depend upon 
> it have been unloaded, so from the perspective of a compiler, it acts
> like library-level. The whole mess about loading/unloading is on the
> user (which is what I meant about "unsafe" yesterday), and if you get
> it wrong, your program is erroneous and can do any manner of things.
> It's no more worth it for a compiler to worry about bad unloading
> than it is to worry about dangling pointers.

Still arguing for collections, huh? (:-))

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