I have a program that uses an inputhandler on OS4. This is attached to the system using a struct Interrupt and the flag NT_EXTINTERRUPT.

Up until now I have allocated all memory, including this struct, that will be used inside the handler as MEMF_PUBLIC since I read that any kind of interrupt or such that isn't executed in my process context must be.

Today I noticed that I could actually allocate all memory including the sturct Interrupt and my userdata as MEMF_PRIVATE and it still works.

Why?? Should I get crashes and lockups and whatever..?

Will I get crashes and lockups in future versions of AmigaOS if I use PRIVATE?

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Yes,the PRIVATE attribute is really intended for the future. As you can imagine, a strict implementation now would break a lot of old apps.

Once the wrapper/"sandbox" for 68k is written and in place, native apps can be forced to use PRIVATE or SHARED memory as required. For the moment, either will still work.

BTW, the implication is that any memory that might be passed to another task for processing (eg disk buffers, StdIOReqs, etc) must be SHARED.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@Deniil715
Quote:

Up until now I have allocated all memory, including this struct, that will be used inside the handler as MEMF_PUBLIC since I read that any kind of interrupt or such that isn't executed in my process context must be.

According to DH1:AmiSDK/Include/include_h/exec/memory.h MEMF_PUBLIC is now obsolete and MEMF_SHARED should be used instead. You have suggested that MEMF_PRIVATE might be appropriate in your case. However, since the docs say that such memory is only visible to the allocating task I wonder if that includes system functions (when adding your interrupt) which would mean you should use MEMF_SHARED. Maybe an expert can tell us if private memory can be shared with system functions or tasks.

_________________
X1000 with 2GB memory & OS4.1FE

@tonyw

Quote:

Yes,the PRIVATE attribute is really intended for the future.

So MEMF_PRIVATE is actually the same as MEMF_SHARED ?

Quote:

As you can imagine, a strict implementation now would break a lot of old apps.

I don't see why as MEMF_PRIVATE is a new tag introduced in OS4 isn't it ?

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@abalaban

No. AFAIK MEMF_PRIVATE can be paged out, while MEMF_SHARED cannot.

_________________
Playstation Network ID: xeron6

@xeron

Yep but what about the memory access ? Does MEMF_PRIVATE allows access only by allocating task or like MEMF_SHARED it can be accessed by any task ?

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@tonyw

Quote:

Yes,the PRIVATE attribute is really intended for the future. As you can imagine, a strict implementation now would break a lot of old apps.

I find that nonsense because PRIVATE is new for OS4 AFAIK and is supposed to allow new OS4 program to allocate protected memory that noone can access except the allocating task. No old programs use this because it didn't exist when old programs were written.

Problem with PUBLIC was that programs used it when it wasn't necessary, and some didn't use it when it would have been necessary if OS3 had MP. This is why OS4 can protect anything not allocated with PUBLIC, instead OS4 had to invent new flags: SHARED and PRIVATE.

But why would PRIVATE really is SHARED in the current OS4.0 and OS4.1 when there really is a memory protection system in the OS which can protect what is told to be protected (using the PRIVATE flag). Why make the same mistake again by introducing flags that aren't in use yet, as was done for Classic with the PUBLIC flag? Zero page is protected, and code is protected such that only executing it will work, and even static constant areas in programs are protected agains writing, so why would PRIVATE memory not be protected from others? I find that odd.

OR, in my case, maybe the memory rights are handled over to the system so that it knows that it is my code that is run, and therefore allows access to my private data, even if it is not my *task* that is executing.

Rogue or EnthilZha, please clear this out for us!

@xeron

Can PRIVATE really be paged out? Isn't it only VIRTUAL that can be paged out??

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715 and others

There's quite alot of info about this in the autodocs. (exec.doc/AllocMem)

This is what I've gleened from reading both the autodoc and the memory.h include. It's my interpretation and open to correction

MEMF_PUBLIC is not depricated or obselete as Xenic suggests, that's not what the include file says.

It says:

 * MEMF_SHARED has replaced MEMF_PUBLIC for almost all applications,
 * starting with AmigaOS release 4.0.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues
Quote:

MEMF_PUBLIC is not depricated or obselete as Xenic suggests, that's not what the include file says.

Thanks for correcting me on that. I completely misinterpreted the comments in the memory.h include file. I should have read the OS4 docs too! Here is what the OS4 Migration guide says:

"The only place where MEMF_PUBLIC should be used if (is?) when your memory needs to be accessible by an interrupt."

That would seem to apply to Deniil's Input Handler as you said.

_________________
X1000 with 2GB memory & OS4.1FE

@Deniil715

Quote:

I have a program that uses an inputhandler on OS4. This is attached to the system using a struct Interrupt and the flag NT_EXTINTERRUPT.

Gee that sounds extreme. Are you using input.device?

Do you think Commodore failed on the commodity.library? I am the only person I know who makes use of it to add an input handler.

Last edited by Hypex on 26-Oct-2008 at 01:27 PM.

@All

Thanks for clearing up and reading the fine print in memory.h and the autodocs. I apparently didn't read close enough. It is also good to know that PRIVATE isn't enforced yet. It is however bad that it isn't enforced yet, because people like me, who like to have as much as possible PRIVATE, may overuse it and crash in the future.

I'd still like a clarification from the OS4 devs on the PRIVATE flag.

@Hypex

Quote:

Gee that sounds extreme. Are you using inoput.device? Do you think Commodore failed on the commodity.library?

Yes I'm using input.device, and yes, the limitations of commodity.library is exactly what my program is designed to overcome. I'm talking about AllKeys (os4depot) here. It's primary purpose is to be able to read keys which aren't defined yet, and hence unreadable by commodities.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Quote:

Yes I'm using input.device, and yes, the limitations of commodity.library is exactly what my program is designed to overcome. I'm talking about AllKeys (os4depot) here. It's primary purpose is to be able to read keys which aren't defined yet, and hence unreadable by commodities.

So are these rawkeys or something else? Have you heard of an InputXpression? You can use it to filter out mouse movements or keypresses as you would know for standard hot keys.

But, I have added a CxCustom function that reads all input events. So anything that the input.device gets should be passed through to the handler. If it has limitations like this I'm not aware of them, perhaps you can fill me in.

@Hypex

Quote:

So are these rawkeys or something else? Have you heard of an InputXpression? You can use it to filter out mouse movements or keypresses as you would know for standard hot keys.

AllKeys reads RAWKEYs, EXTENDEDRAWKEYs (these are for MM-keys and the prime reason I wrote the program), WHEEL codes and MOUSE codes.

I haven't heard of InputXpression. Is it a key reader and program dispatcher, or what does it do after it has read a key?

Quote:

But, I have added a CxCustom function that reads all input events. So anything that the input.device gets should be passed through to the handler. If it has limitations like this I'm not aware of them, perhaps you can fill me in.

I don't know if there are any limitations of a custom CxCustom function. Didn't look into it very close since it seemed easier to just hook up directly to the input.device. I also wanted to go as low as I could. First I thought about going directly at the PS/2 port somehow but that seemed a bit tricky As far as I know Cx can only filter named keys, such as "rcommand shift k" etc. What if I wanted that button with a moon on it?

The nice thing with input.device is that I can set my handler at a higher priority than the whole commodities handler effectively blocking out keys from a screen blanker. Also, hooking to commodities would just add another step in the way I felt.

I used commodities for reading hotkeys for a program once but found it awkward when I needed a large number of hotkeys. Input.device was simpler. I could also put it in record mode and let the user type any unknown keys and the code just pops up and can be used. This works for commodities also - if you know the name of the keys.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@broadblues

Quote:

There's quite alot of info about this in the autodocs. (exec.doc/AllocMem)

Unfortunately it doesn't correspond with what I've been told:

MEMF_PRIVATE is the only type which can be paged out to disk.
Even MEMF_ANY won't give you MEMF_PRIVATE. Apparently this is a compatiblity thing.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@Deniil715

Quote:

I'd still like a clarification from the OS4 devs on the PRIVATE flag.

MEMF_PRIVATE is for memory that is used by this task only. That is, any memory that is flagged MEMF_PRIVATE must not be used outside of the task. This means that messages, interrupt structures, or anything else that must be used from outside the task MUST NOT be declared private.

There is nothing right now that enforces this policy.

Anything that is marked as SWAPPABLE, including swappable private and shared memory, can be swapped to disk. By default, PRIVATE memory is swappable, and shared isn't.

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

@Rogue

Quote:

MEMF_PRIVATE is for memory that is used by this task only. That is, any memory that is flagged MEMF_PRIVATE must not be used outside of the task. This means that messages, interrupt structures, or anything else that must be used from outside the task MUST NOT be declared private. There is nothing right now that enforces this policy.

Ok. Thanks for the explanation, but of course I have some follow-up questions :
When do you plan on enforcing protection on PRIVATE memory and why wasn't that implemented when the flag was made available? I have probably overused this flag quite a lot by now, and also dismissed some memory corruption and crash bugs because "my memory is protected and no one can touch it"...

What is the definition of "outside my task"? (It's difficult to know when AmigaOS takes some data to another task, or when it acts directly within my task.)

Are these legal or illegal for example:
buf=AllocMem(size,MEMF_PRIVATE);
SetWindowTitles(win,buf,NULL) ?
Fwrite(fh,buf,1,size) ?
Fread(fh,buf,1,size) ?
IAnyLibrary->Function(buf) ?
BlitBitMap(win,buf,...) ?
PrintIText(rport,buf,..) ?
Text(rport,buf,..) ?

What I can imagine is illegal is userdata for an interrupt or handler routine (such as mentioned in this thread), or DoIO buffer, or of course msg.data that is explicitly shared between tasks.

Perhaps this will become painfully clear when the PRIVATE flag enforces actual protection...

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

A good way to approach MEMF_PRIVATE handling would be to make it available as an optional feature (via some sort of switch) so developers could transition to it. At some future release date the option would disappear.

I think to blindly enforce it at some point would cause a lot of pain.

i.e. OS 4.1.x has MEMF_PRIVATE as optionally enforced.
OS 4.x has MEMF_PRIVATE enforced.

The other option is to make it available in a beta release but I don't think that would expose the feature widely enough.

@Deniil715

Quote:

AllKeys reads RAWKEYs, EXTENDEDRAWKEYs (these are for MM-keys and the prime reason I wrote the program), WHEEL codes and MOUSE codes.

Yes. That should be possible.

Quote:

I haven't heard of InputXpression. Is it a key reader and program dispatcher, or what does it do after it has read a key?

It's the CxFilter structure. As you know you can give Cx strings such as "rawkey ctrl lalt f1" to filter out a hotkey. However filling out and giving a direct InputXpression will do that andmore as it's binary based. Meaning you can tell it to filter out an exact Class, Code and Qualifier. Look here:

Quote:

struct InputXpression { UBYTE ix_Version; /* must be set to IX_VERSION */ UBYTE ix_Class; /* class must match exactly */ UWORD ix_Code; /* Bits that we want */ UWORD ix_CodeMask; /* Set bits here to indicate which bits in ix_Code * are don't care bits. */ UWORD ix_Qualifier; /* Bits that we want */ UWORD ix_QualMask; /* Set bits here to indicate which bits in * ix_Qualifier are don't care bits */ UWORD ix_QualSame; /* synonyms in qualifier */ }; typedef struct InputXpression IX;

Quote:

I don't know if there are any limitations of a custom CxCustom function. Didn't look into it very close since it seemed easier to just hook up directly to the input.device. I also wanted to go as low as I could. First I thought about going directly at the PS/2 port somehow but that seemed a bit tricky As far as I know Cx can only filter named keys, such as "rcommand shift k" etc. What if I wanted that button with a moon on it?

That is low! AFAIK Cx was mean to ease the use of key handlers and provide a standard interface. And an upperlayer so the programer didn't have to use input.device. By convention a library has always been easier to call on than a device. Like OpenWindowTags() replaced OpenWindow() and SystemTags() shoud be called instead of Execute() Cx was meant to be friendlier. However, as you point out, it just hasn't caught on as well as it should have. Not to mention Detlef Wurkner said there is nothing wrong with using input.device when I thought he would have told me to use the more modern commodities.library.

I guess I studied it a bit more than most as I wanted to use the most modern methods in my programs. Oh well.

BTW, is AllKeys a commoditiy?

As to the moon, yes I see no reason why not, in a custom CxHandler you can read the InputEvent.

Quote:

The nice thing with input.device is that I can set my handler at a higher priority than the whole commodities handler effectively blocking out keys from a screen blanker. Also, hooking to commodities would just add another step in the way I felt.

It will give you greater control. Which Cx was meant to stop people doing and provide a go-between so the system wasn't messed up. So would these keys be between the input.device and Cx? As Cx lets you remove keys from the input stream normally. As is required for hotkeys.

Quote:

I used commodities for reading hotkeys for a program once but found it awkward when I needed a large number of hotkeys. Input.device was simpler. I could also put it in record mode and let the user type any unknown keys and the code just pops up and can be used. This works for commodities also - if you know the name of the keys.

I guess Commodites adds more features and so is more complicated as you need to know about what it can do if you have a need for something. It also lets you use a routine and not require an interrupt. Once a plus. The only time I really have found it awkward is when I programmed a hotkey but then wanted to "hear" WINDOWACTIVE events. I couldn't get it to add a filter in or even as I needed, remove the hotkey and replace it with the other event so I could wait until the current window was activated.

Last edited by Hypex on 03-Nov-2008 at 01:55 PM.

@gregthecanuck

Since it has been so long now since the flag was introuced, but the actual protection hasn't been introduced, perhaps a transitional period would be needed.

I think it's too bad they sort of made the same mistake as with the PUBLIC flag; introduce it long before it is enforced.

I have no idea how many programmers have (over)used the PRIVATE flag by now. Perhaps not many, or maybe a lot..?

@Hypex

The InputXpression could very well have solved my problem, but I didn't knew about it.

Quote:

BTW, is AllKeys a commoditiy?

Yes it is, but it doesn't define any hotkeys that way
You can enable and disable the handler through Exchange though!

Quote:

It will give you greater control. Which Cx was meant to stop people doing and provide a go-between so the system wasn't messed up. So would these keys be between the input.device and Cx? As Cx lets you remove keys from the input stream normally. As is required for hotkeys.

Yea, one better not make mistakes or input.device will crash on you, locking you out AllKeys' input handler does a minimal amount of work, then signals the main AllKeys process to do stuff, such as start programs or execute arexx.

The input priority of AllKeys is user-definable so you can set it to any level you want. Intuition is at level 50 and Cx at 60 I think. AllKeys defaults to 70.

The multimedia keys doesn't do anything except flow through input.device as EXTENDEDRAWKEYs ready to be picked up. The screenblanker listens to them too though, so they need to be filtered out if one for example want's to change the volume of Mixer without waking up the monitor.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Quote:

Yes it is, but it doesn't define any hotkeys that way You can enable and disable the handler through Exchange though!

And to think the commodities.libray could have do all this for you in one API.

Quote:

The input priority of AllKeys is user-definable so you can set it to any level you want. Intuition is at level 50 and Cx at 60 I think. AllKeys defaults to 70.

Right above! The examples I read had it at 51. Just.

Quote:

The multimedia keys doesn't do anything except flow through input.device as EXTENDEDRAWKEYs ready to be picked up. The screenblanker listens to them too though, so they need to be filtered out if one for example want's to change the volume of Mixer without waking up the monitor.

Sounds handy. I myself just use the volume controls on my monitor.