Re: Custom Storage Pool questions

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:sk8mbv$15ca$1@gioia.aioe.org...
> 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.

Testing cannot ensure that a contract hasn't been violated, especially the 
implicit ones that get created by the runtime behavior of a library. At 
best, you can test a few percent of the way a library can be used (and 
people are good at finding unanticipated ways to use a library).

>> (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.

??? Your "test application" is just a way of running unit tests against a 
library. You can surely do exactly the same testing with a statically-linked 
library, it's hard to imagine how a library is packaged would make any 
difference.

The problem with dynamically loaded libraries is exactly that they change 
out of sync with the rest of the application, and thus tend to break that 
application when some behavior of the original library is changed. It's 
quite possible that the behavior in question should never have been depended 
upon, but contracts aren't strong enough to really describe dynamic behavior 
(especially use cases and timing). At least with a statically linked 
library, you know it won't change without at least rerunning your acceptance 
tests.

>> 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.

I agree with the sentiment, but the only way to get any sort of 
maintenability is with strong contracts and lots of static analysis. 
Otherwise, subtle changes in a library will break the users and there will 
be no way to find where the dependency is. Nothing I've ever worked on has 
ever been close to maintainable because there is so much that Ada cannot 
describe (even though Ada itself is certainly a help in this area). You just 
have to re-test to make sure that no major problems have been introduced 
(there's a reason that compiler writer's rerun a huge test suite every day).

>>> 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.

Only if you don't use unit tests. But then how you can test a dynamic 
library escapes me. (I've never used unit tests with Janus/Ada because it is 
too hard to set up the initial conditions for a meaningful test. The easiest 
way to do that is to compile something, but of course you no longer can do 
unit tests as you have the entire rest of the system dragged along.)

> Dynamic libraries flatten that. Yes, this requires normalization of 
> plug-in interfaces etc.

As noted above, I don't see how. If testing a dynamic library is possible, 
surely running the same tests against a static library would give the same 
results (and assurances).

...
>> 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.

That sort of stuff is just plain evil. :-)

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.

...

...
>> 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.

Ada,Tags can be implemented dynamically; it's a lot easier to do so with 
nested tagged types whose tags go away. Essentially, one registers tags when 
they are declared, and deregisters them when they go away. That fits very 
well with dynamically loaded libraries.

>> 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 dispatching tables are defined statically by the compiler, and never 
change. What I'd do for dynamically loaded libraries is use a wrapper that 
indirectly calls the dynamically loaded libraries' subprograms. So loading 
the library (actually, declaring the extension) simply has to set up an 
array of pointers to the dynamically loaded subprograms. (You can't call 
them statically because you don't know where they'll be.) The dispatch 
tables never change.

>> 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.

They're still treated as library-level, and they can only be loaded before 
anything that is going to use them. Otherwise, the Ada elaboration model is 
hosed, and that is fundamental to compiling Ada code.

You could of course write an implementation that doesn't care about safe 
code, and let people do whatever that they like even though it is nonsense 
from an Ada perspective. Such code is simply user-beware, and has no 
guarantee of working in the future (after a compiler change).

I won't do that, there are some principles that I won't compromise to get 
customers.

                             Randy.