From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,XPRIO autolearn=no autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!weretis.net!feeder8.news.weretis.net!newsfeed.xs3.de!callisto.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Thu, 14 Oct 2021 19:36:42 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Fri, 15 Oct 2021 00:36:43 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="6794"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:63003 List-Id: "Dmitry A. Kazakov" wrote in message news:sk8mbv$15ca$1@gioia.aioe.org... > On 2021-10-14 03:21, Randy Brukardt wrote: >> "Dmitry A. Kazakov" 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.