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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!Hx95GBhnJb0Xc8StPhH8AA.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Thu, 14 Oct 2021 09:31:11 +0200 Organization: Aioe.org NNTP Server Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="38282"; posting-host="Hx95GBhnJb0Xc8StPhH8AA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:62997 List-Id: 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. > (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