@Kronos

Quote:

In both cases classic-SW can't directly communicate with new SW

Says who? I don't see any reason why new software wouldn't be allowed to map a piece of their memory as public and do a normal PutMsg, or why a task running unprotected cannot PutMsg to a message port, as long as there is some memory that they can share.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

@Toaks

Quote:

sorry but this thread has become an "MY FATHER IS STRONGER THAN YOUR FATHER" type of thread...

[heavy breathing]
No, Toaks... I am your father...
[/heavy breathing]

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Its a shame that all messages aren't allocated by the programmer using MEMF_PUBLIC then freed by the recipient application when its done , then they could be identified as being in a shared address space. But then I don't actually use ReplyMsg that often so I realise thats a case where this programming model wouldn't help anyway.

The only bit I find hard to let go on is going from being able to happily using shallow copy cloning to now feeling I need to move closer to deep copy cloning in my applications in order to get full MP benefits.

( degarbled a bit )

Last edited by DaveP on 09-Dec-2004 at 08:29 PM.

@GregS

Quote:

Seriously I would love to be using Papyrus again, and as far as I know there is no PPC WP avialable for OS4. You have at least one customer in waiting.

I will buy it at once and BURN-IT too if available for AOS4.
Please Titan Computer do this port!

_________________
A computerworld without MS products and Windows!
Connect your Amigas ...
...The Red ONE-A1XE G4 - A3000T- A3000 - A4000 - A2500- A1000 - A600 - CDTV - CD32...
and your PDAs and laptops ...
Psion 5mx Pro - Psion NetBook - Apple iPhone - MacBook Pro

- Lord EntilZha!
- Yes, Master!
- Rise.

_________________
Álmos Rajnai

@Rogue

I guess, the key question is, what performance hit will have the!memory protected messaging, not the new API (when handily designed). Will it copy the whole msg to the port ? .... I gues Entzilha hinted something some time ago.
???

re

Treke

@Treke

Well thats the rub isnt it? All the prereqs to allow by copy messaging are there including most programmers sticking to setting the length field in the message header as they should.

However, messages often contain pointers to other data held in the first task, so that would make this a shallow copy clone only mechanism. Would the pointers be valid in the target task? Would it be possible to check every message and specifically authorise the memory allocated in each address to the target task? Or should all memory allocated that is passed by pointer in a message be allocated in public shared memory?

Thats why I brought up deep copy cloning above where the application does not just copy the addresses but the addresses are pointers to objects that are serialisable. The initiating task serialises all pertinent data and transmits that to the recipient.

Personally I don't like deep copy cloning where I don't have to ( inside the same host on the Amiga ) but always implement a clone method on my objects when it crosses host boundaries.

It would be interesting to see what route is adopted and what additions this brings to the programming model.

@DaveP

Quote:

Well thats the rub isnt it? All the prereqs to allow by copy messaging are there including most programmers sticking to setting the length field in the message header as they should.

That's not enough. Often the messages contain pointers to private data, and that data doesn't get copied together with the message, which means that data has to be in public memory as well.

This also happens with system's data structure, which in turn means that the OS itself has to have its own private structure in shared memory, which in turn means anyone could mess with that memory and crash the whole OS.

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

@falemagn

Sending messages with pointers to private data is about the worst programming style one can think of. Ok, apart from accessinhg kickstart functions by jumping into the ROM maybe
New applications will have to play by some rules. Use MEMF_SHARED for public data, MEMF_PRIVATE for private data. Old applications usually use MEMF_PUBLIC anyway which will always be public and therefore accessible.

And I don't know about cases where the system sends around messages which point into internal system structures.

_________________
"Who do you think is this guy - god ?"
"No, god knows mercy !"

@falemagn

I totally agree, thats what I meant about deep copy cloning in the later paragraphs.

@Mr.Return

Quote:

Sending messages with pointers to private data is about the worst programming style one can think of.

Not on AmigaOS, obviously, since there's not been so far the concept of private memory. AmigaOS applications are ridded with such things, and it's completely legit.

Quote:

Ok, apart from accessinhg kickstart functions by jumping into the ROM maybe New applications will have to play by some rules.

New applications aren't the problem, the problem is the coexistence of new and old applications, because to make old applications work, old semantics have to stay together with new ones, rendering the new ones at all effect uneffective.

Quote:

Use MEMF_SHARED for public data, MEMF_PRIVATE for private data. Old applications usually use MEMF_PUBLIC anyway which will always be public and therefore accessible.

That's the problem: public memory can be trashed. Also, since in AmigaOS there's no concept of ownership of resource, you can't share that memory just with the target of the message.

Quote:

And I don't know about cases where the system sends around messages which point into internal system structures.

Just think of intuition messages, input device messages, and basically anything in the OS that needs to give some information about something OS-related.

It's not just about messages, though, AmigaOS is full of open structures which applications are free to peek from and poke in.

It just is not possible to make AmigaOS a secured operating system and make it stay compatibile with the current AmigaOS.

Last edited by falemagn on 10-Dec-2004 at 11:47 AM.
Last edited by falemagn on 10-Dec-2004 at 11:46 AM.

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

@Mr.Return

Quote:

Sending messages with pointers to private data is about the worst programming style one can think of.

Unfortunately, Fabio's right: This is common practice.

Quote:

And I don't know about cases where the system sends around messages which point into internal system structures.

IntuiMessages ? AFAIR, they might contain pointers to the TabletData, among other things...

However, for the system, this isn't too much of an issue.. it can be changed to handle those cases correctly.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@EntilZha

Quote:

However, for the system, this isn't too much of an issue.. it can be changed to handle those cases correctly.

Some could be changed, yes, by making a deep copy of all the relevant data (a work which would be highly complex and thus time consuming, though), but in many cases this just is not possible, both because the structure tree height would be too high (ok, you could stop at a certain level, trading compatibility for speed), and because sooner or later you might encounter pointers to other tasks data. You incurr in the risk of having to do a snapshot of the state of the whole OS just for sending one little message.

I ask: is it worth even the engineering effort it takes? To me it seems a dead end, there are far better alternative solutions to the problem, imho, like simply declaring the whole AmigaOS obsolete, keeping it in its own box, and implementing a totally new API for new applications which will live in their own world, sharing as much as possible with old applications. Kind of how the UAE integration in AROS will have to work.

Last edited by falemagn on 10-Dec-2004 at 12:04 PM.

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

@DaveP

Quote:

Personally I don't like deep copy cloning where I don't have to

Yup.
I'm afraid the deep copying with full MP will kill the amiga's killer argument, the agility.
And ... more msg passing schemes with _totally_ different API is not a good way, IMO. The system looses the orthogonality, understandability and predictability (system cannot rely on something it doesn't enforce - the not protected msg passing).

Generally, when the message sending task creates the deep copy of the message, it wastes and unpredictable amount of resources, because it cannot know what data will be used (especially when pointers are 'reincarnated' in the second task's address space - pointers to methods - huh. ). The agile way is copying what is needed.
I'm not sure this is impossible with MP. If it is possible, even with different API, this is a way to go, IMO. Offcourse, the backward compatibility, should be maintaned to some extent (but not as the encouraged way to use the system - two API-s,bad, IMO)
Hmm.

re

Treke

I'm afraid this was my longest post for a long time Even worse if clueless

@falemagn

The final option ( and this would not be easy to implement for system objects but maybe as a new programming model ) would be akin to object based application servers where objects are accessed through a proxy object and the proxy object itself is copied.

This would be simple to demonstrate with templates and smart pointers in C++ but it would still require a level of indirection ( say an ORB ) to allow methods and addresses to be marshalled and demarshalled between the calling application and the data/logic holding object server space. Of course that would be limited to those applications that used this system.

Maybe all system level allocations that could be used through system mechanisms such as intuition are all in shared memory and therefore addresses to those are valid.

There are ways around all of these problems, it just takes time, hard thought and perhaps it might even be "slow" with all the inspections and interceptions that would be required to determine what accesses are valid and which should result in a violation. Time will tell which method, mechanisms the Friedens use and whether or not it produces any noticeable slowdown compared to the current freeforall in Exec.

@Treke

No its fine. Not at all clueless.

There are two ways of deep copy cloning:

1. The system works it out, as Fabio pointed out this is cripplingly slow, innaccurate and really not the way to go.

2. The application programmer/programming model works it out. This is faster but still as you say removes one of the killer features of the Amiga programming model. Pass by reference.

What would be the best consideration in my view is that passing an address in a message is a tacit authorisation to either the entire address space or only the allocations referred to by address in the message.

Thus tasks can still access each others permitted allocations. They effectively opt in.

Whether its possible to produce this or not without a serious burden on an MMU unit I don't know.

I don't see yet a reason to give in and say "anything that uses exec messaging is unsable, instead use this seperate api/method that we introduce in OS4.1" but then Im not Thomas

@DaveP

Quote:

The final option ( and this would not be easy to implement for system objects but maybe as a new programming model ) would be akin to object based application servers where objects are accessed through a proxy object and the proxy object itself is copied.

But that doesn't work out for the current applications. Current applications will still want to access data the old way, and unless you want to bring the system on its knees by intercepting all accesses to system structures via MMU, there's no way to retrofit a component model of that kind in the current AmigaOS.

_________________
“It is well enough that people of the nation do not understand our banking and monetary
system, for if they did, I believe there would be a revolution before tomorrow morning.”
~~ Henry Ford

@falemagn

True.

@DaveP

Quote:

What would be the best consideration in my view is that passing an address in a message is a tacit authorisation to either the entire address space or only the allocations referred to by address in the message.

I don't see the problem in the 'message allocation only' method, you advise. It would just enforce good programming practices. Passing only data, and deserialize them by methods of some shared lib.

[architect_hat_ on type="speculation"]

Only problem I see is how to enforce (by API), that the sending task doesn't change the data (by any hack), while the receiving task is using them. After all, the address is at that time accessible from 2 different isolated task spaces.

A solution could be to encapsulate the transmitted data into objects and passing the refs to these objects. Objects with defined interfaces. Data in objects should be acccesible only through the interface of the object. After PutMsg(or similar call), the sender could not access the data in the object (method call blocks on the object) until ReceiveMsg (or similar) call is called on the message by the receiver task. So it is just a fake for locking the data in the shared memory.
AFAICS this is a combination of your2 proposals

But this is O-O, defective, insufficient for system API.

[/architect_hat_on]

re

Treke

@falemagn

Quote:

I ask: is it worth even the engineering effort it takes?

I tell you when it's done

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment