Wither Natami?

[Piru]

You said that basically the whole shared library method would have to be discarded due to memory sharing issues.

And my example only provided one reason for it.

Others include the problem the fact that you'd need to have different library base per caller. Something that doesn't work with many libraries.

I need a solid example why a library would need to allow multiple callers to access structures allocated by the other.

diskfont.library, dos.library, asl.library, locale.library, rexxsyslib.library, realtime.library, commodities.library, datatypes.library, card.resource, timer.device, keyboard.device, trackdisk.device, graphics.library, intuition.library, layers.library, gadtools.library, exec.library, utility.library at least.

Of 3rd party libs reqtools, xadmaster, xfdmaster, openurl, muimaster, ixemul at least.

[Piru]

@Hans_

Naming libraries is not a solid example.

So if I explain why one of the libraries requires it will that be enough for you? (The same problem is in all of the libraries I listed. It is the very same problem I tried to demonstrate with the example library code, but apparently failed miserably)

[Piru]

@Hans_

utility.library/AddNamedObject
utility.library/RemNamedObject
utility.library/AttemptRemNamedObject

These named objects are in a global tree which can be modified by any caller. For additional headache, the objects can be removed by different task, too. Read the autodocs for details.

This stuff is clearly broken if each task has it's own memory space.

dos.library/AddDosEntry

This function adds the given dosentry to the internal global doslist. Some things (filesystems, apps) allocate the dosnodes themselves and pass them to the AddDosEntry (among other things it means you can't safely free a dosentry you remove). With MP this concept would be horribly broken.

dos.library/LoadSeg
dos.library/UnLoadSeg

LoadSeg allocates memory for the segments in the context of the caller. Yet somehow this memory should at some point change ownership. Similarily UnLoadSeg is often called by different task than that called the LoadSeg. Shell and Workbench do this, aswell as ramlib (see below).

ramlib
exec/OpenLibrary
exec/OpenDevice
exec/OpenResource
exec/AllocMem etc

ramlib calls LoadSeg to load the library/device/resource, yet expunge gets called by totally unrelated task:

If system runs out of memory or "avail flush" is performed, the system will attempt to free memory by calling the "lowmemhandlers". These handlers get called in the context of the AllocMem caller, meaning that different task will call library/device/resource Init and Expunge vectors.

I'll add more examples if needed.

[Piru]

@Hans_

You've identified a number of issues with existing APIs that would indeed have to be addressed, but nothing that I would say kills the shared library system.

The MP issues I've listed are just part of the problem, more like annoyances, icky things you would need to fix all over the place. There are other similar issues that add to the workload, such as global variables being used on disk based libraries.

Each caller would need to get their own library base. Also, to allow static data (disk based libraries) you'd need to somehow clone the data hunks for each caller and handle the relocation. In all this would end up being closer to .so than the classical shared library system. Thus my claim that it would kill the shared library system (as we know it).

This all combined with other problems introduced by SMP, resource tracking etc make me wonder if this would be worth the trouble.

This is my view. If you don't agree, fine.

[Piru]

Except the 7 years were a lot easier than what is suggested here. We built the OS on solid ground, well perhaps not made of rock, but it was solid enough for us.

I wouldn't want to start now by drying up some wetland.

:-)

[Piru]

No memory protection and self modifying code I think are assets to the field of Artificial Intelligence.

How exactly?

[Piru]

Software collects data and makes decisions on what to do, but how about generating new code to make decisions from logic as opposed to merely collecting data and reacting? Saving these new program segments and running them. Then perhaps joining some together. This is how I think AI could work.

Memory protection does not prevent any of this, though what you wrote here has no extra benefit whatsoever for AI (naturally you CAN use code generation, but there is no benefit from it).

Rest of your comments deserve no reply, I'm afraid.

[Piru]

If it weren't the case, I'd close down my membership here at Amiga.Org

It isn't the case.















Here's hoping...