Re: Custom Storage Pool questions

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

On 2021-10-14 03:21, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:sjbq96$3cl$1@gioia.aioe.org...
>> On 2021-10-03 06:33, Randy Brukardt wrote:
> ...
>> Yes, but static monolithic linking is even more fragile. Typically a
>> customer orders software off the shelf. It means that he says I need, e.g.
>> HTTP client, ModBus master, CANOpen etc. It is simply impossible to
>> re-link everything for each customer and run integration tests.
> 
> ??? When you are dynamically loading stuff, you simply are assuming
> everything is OK.

A relocatable DLL is tested with a test application.

> (Which is usually nonsense, but for the sake of argument,
> assume that it is OK to do.) When you statically link, you surely can make
> the same assumption.

A static library is tested same way, true, but integration of a static 
library is different and testing that is not possible without developing 
some massive tool-chain, like Linux distributions had in early days.

> Of course, when you statically link Ada code, you can include that code in
> your static analysis (including, of course, the various guarantees that the
> Ada language and compiler bring). When you dynamically load, you can have
> none of that.

Yes, but maintainability trumps everything.

>> So the software is organized as a set of plug-in relocatable libraries,
>> each of them maintained, versioned and tested separately. You cannot turn
>> clock 20 years back.
> 
> And you still have to do integration testing when using them together -- or
> you could have done the same at the Ada source code level (that is, version,
> maintain, and test separately) and still have the advantages of Ada
> checking.

Theoretically yes, in practice it is a combinatorial explosion. Dynamic 
libraries flatten that. Yes, this requires normalization of plug-in 
interfaces etc.

> ...
>>> Of course you can.
>>
>> How? Ada does not determine the way you link an executable. If I put a
>> package in a library it is there. If the package derives from a tagged
>> type
> 
> This I don't understand at all. A dynamically loaded library necessarily has
> a C interface (if it is generally useful, if not, it might as well be
> maintained as Ada source code, there's no advantage to dynamic linking in
> that case and lots of disavantages), and that can't export a tagged type.

No C interfaces. Apart from maintenance, other issues are licensing and 
security. A typical case is a component that is licensed in a different 
way or may not be shipped to other customers at all. And you can have 
alternative or mutually incompatible components.

> In any case, a tagged type extension is a compile-time thing -- the compiler
> has to know all of the details of the type.
> 
>>> The only thing you need to be compatible with is a C interface, which
>>> is the only thing you need to interface to existing libraries that
>>> you can't avoid.
>>
>> That would kill most of Ada libraries.
> 
> There's no use to an Ada dynamic library -- if it's only for your
> organization's use, static linking is way better.

You compare static vs. import library. The case I am talking about is 
static vs. late dynamic loading, i.e. dlopen/dlsym stuff. And, yes, we 
do dlsym on entries with Ada calling conventions. No C stuff.

> And if it is for
> everyone's use, it has to have a C interface, thus no tagged types.

We have close to a hundred of dynamically linked Ada libraries. Only one 
of them has C interface, not surprisingly, with the sole functionality 
to provide C API. But even that one library has tagged extensions of 
inside of it. The standard Ada library is full of tagged types. Your 
C-interfaced library is free to derive from any of them. You cannot 
prevent that.

>>>> So getting rid of nesting tagged types will ease nothing.
>>>
>>> The problem is tagged types not declared at the library level.
>>> Relocatable librarys are still library level (they have their own global
>>> address space).
>>
>> When the library is loaded dynamically, there is no way to know in the
>> executable the tag of the extension or prepare an extension of the
>> dispatching table. I think it is far worse than a nested declaration, when
>> is you have some information.
> 
> Ignoring that fact that this is useless construct, it is not at all hard to
> do, because you have to know that the tag and subprograms are declared in
> the dynamically loaded thing.

I do not see how this helps with, say, Ada.Tags.Expanded_Name getting a 
tag from the library as an argument.

> Thus, one has to use a wrapper to call them
> indirectly, but that's easy to do when everything is library level. It's
> essentially the same as shared generics, which Janus/Ada has been doing for
> decades -- including tagged type derivation.

That is OK, but you still have to expand dispatching tables upon loading 
the library and shrink them upon unloading (though the latter is not 
supported, I guess).

> The problem comes about when you have things whose lifetime is limited and
> need to have a static link or display to access them. Managing that is a
> nightmare, no matter how you try to do it.

The lifetime of library objects in a dynamically loaded library is 
limited by loading/unloading of the library.

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