The OS4 direction thread

[Piru]

It's rather weird that OS4 coders are incapable of creating library with per-task sdata. It's rather trivial with -mresident32 and small r13-restoring code snippet. With such code, only the library base itself and static variables need to be allocated per library opener. This is the most efficient and natural way to handle it, and it's far from painful.

Funniest comments regarding this have come from some guys claiming various MorphOS programs are statically linked due to missing "feature", when in fact MorphOS has had it for years, and implemented properly.

[Piru]

@Hans_

Apparently that's quite ok with a shared object, because each process that links to the shared object has it's own local var space. To me, it just looks like a thread unsafe time-bomb waiting to happen. It's bad coding practise. What happens if you use such code from multiple threads within the same process?

Depends. If you're on unixy system, it works out of the box. On MorphOS you can adjust the code or use relskeleton library model.

In many cases you're not writing the whole library from scratch. Quite a lot of lib code assumes that it is not shared between processes, that there is a separate memory space.

If you're writing your own code, you obviously can do the thing properly from the beginning, but often this is not the case. You can use the MorphOS relskeleton library model easier than actually rewriting tons of unfamiliar code.

I like the fact that I can decide what is global and what is local to a library opener.

This can be done easily with the relskeleton model. By default all static variables are local. To get "real" global variable just place it to section other than .sdata:

Code: [Select]

int reallyglobal __attribute__ ((section (".realsdata")));
Also, another neat feature of the thing is that you can have a "init-once" variables, that is that any local variable can be preset at LibInit, and it will be copied to all children-libraries. This is quite nice for library bases and such.

Really, I think that they created shared-object loading facilities so that you can just take some cross-platform source code, type make, and build the app

Well, you don't really get very well functioning stuff that way. And what happened to ixemul anyway? It actually works amazingly well on many such occasions (and you hardly ever really absolutely need shared-object stuff in quick compiles anyway).

without having to write library frameworks (a lot of extra work).

Actually the relskeleton framework is quite simple. Also, it doesn't involve changing millions places in the sourcecode (However, naturally some sources require more work than others). I'll much rather take proper library that doesn't gobble tons of memory and resources just because coders were lazy and/or incompetent.

It's also less of a problem if someone adds/removes functions to/from the shared-object (I think that removing functions from a library after release is a bad idea, you're breaking compatibility).

Huh. You never remove functions or insert new ones before the old. You only declare them obsolete, and wrap the old API so that it can use the services of the new, thus keeping binary compatibility. If the API changes completely, just create a new library (change the name) instead. This should be quite obvious.

Then there's the issue of some shared-objects wanting to link to external global variables. I can't think of any clean way of doing that with a library (I also don't think that a library should have external dependencies like that).

I'm not quite sure what you mean by that, but assuming it's just having some "really" global variable: the section trick does the job just fine, if you really must. If you just need some variable from other loadable component, you can do this quite easily too. There are various way to do this, for example fields in public library possize, or some function to return the variable pointer.

And finally: This relskeleton stuff is nothing magic, it's actually old news. Even SAS/C did it decades ago already.

I frankly don't understand why OS4 can't have the same.

[Piru]

@Hans_

Ixemul doesn't provide you with all the libs that a Unix system has.

And it never was supposed to. You're supposed to download the src, unpack, configure and make. Yes, static libraries mostly, but for quick'n'dirty stuff it works just fine. If you use the particular library in many things, you can make it real shared library easily.

Having them use shared objects will at least not waste my HD space.

But it's quite trivial to have both small disk and memory usage. So why not use the best method?

I know it's not complicated to write an Amiga library wrapper framework, but it takes a lot longer than simply typing make and hitting the enter key.

It depends on what you want.

If you want amiga application, you need to work on it anyway, just doing simple configure + make doesn't give you a working Firefox.

Anyway, relskeleton example library is available from the MorphOS Developer Connection. It's simple copypaste job to adjust it for whatever project needed. It really is rather easy stuff, and the benefits IMO easily make it worth the effort.

Huh. You never remove functions or insert new ones before the old. You only declare them obsolete, and wrap the old API so that it can use the services of the new, thus keeping binary compatibility. If the API changes completely, just create a new library (change the name) instead. This should be quite obvious.

Maybe YOU don't. However, that's the reason why sometimes v5 of a particular .so is incompatible to v4. I think it's a really stupid thing to do as this means you need new versions of all apps that used that .so (not a big problem if it's all open source, but it's still not good). Some people do mess with functions in shared objects this way.

relskeleton can actually help: The shared library can easily "drop" old incompatible library entries, and mark them obsolete, and then assign new function slot for the new call with the new API. Thus old applications will call the LVO of the old function, new applications will call the LVO of the new function. Both will continue to work. This works because the functions are not searched by name, but the function references are translated to offsets which will stay fixed. Obviously with a library API in constant flux this will explode the library-base quite fast, so at some point new library name migth be a good idea. So here shared library actually is beneficial.

What I mean is that shared objects can also have, for example, something like: extern int appGlobal. The application would be expected to provide this global variable.

Right. Such thing is pretty fubared up indeed, but luckily not that common in sensible APIs, most of such things are passed to the function in question as argument.

There's no technical reason why they couldn't.

Really? So why don't they? For example python would work perfectly fine as a real shared library, and then it would not eat as much memory, either.

MorphOS python binary is 9KB, while python.library is 1.2MB. The library is loaded to memory once.