RxMUI notify storm control
  • Butterfly
    Butterfly
    alfie
    Posts: 89 from 2005/3/25
    From: Italy
    Hi,

    so... So many years (more than 15 for sure) since last time I switched my peg on; it means I actually forgot everything about amiga/mos.

    In RxMUI, let's suppose you created two radio objects, r1 and r2 and set up a couple of notifications as
    r1 -> r2 everytime active changes triggervalue
    r2 -> r1 everytime active changes nottriggervalue

    to avoid the "notifications storm" that the above starts, I simply check if the stack is less than a specific value in OM_SET; if so, 0 is immediately returned

    this worked fine in 68k, but it doesn't work in ppc, the system simply freezes and that's it

    why?

    what can I do about it?

    note that rxmui is 68k
  • »17.05.24 - 11:43
    Profile Visit Website
  • MorphOS Developer
    jacadcaps
    Posts: 3020 from 2003/3/5
    From: Canada
    MUI has a concept of NoNotifySet which needs to be used to avoid circular notifications.
  • »17.05.24 - 16:52
    Profile Visit Website
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    analogkid
    Posts: 663 from 2004/11/3
    From: near myself
    Quote:

    alfie schrieb:
    Hi,

    so... So many years (more than 15 for sure) since last time I switched my peg on; it means I actually forgot everything about amiga/mos.




    Sorry for being offtopic.. it would be great if you consider updating AmRSS with SSL support.
  • »17.05.24 - 17:03
    Profile
  • Butterfly
    Butterfly
    alfie
    Posts: 89 from 2005/3/25
    From: Italy
    @jaca
    yes, but I am talking about a context where we are in an arexx macro, so users should be free to do whatever they want and so they could make errors without freezing the system. I can't understand why what I can do to replicate the stack check under mos.

    @analogkid
    Ohhhh, I wish I had time and mental resources to do that; I remember htmlview was obsolete 20 years ago... Is there some other mcc to use as html view?


    [ Edited by alfie 17.05.2024 - 18:24 ]
  • »17.05.24 - 17:23
    Profile Visit Website
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    analogkid
    Posts: 663 from 2004/11/3
    From: near myself
    Quote:

    alfie schrieb:
    Ohhhh, I wish I had time and mental resources to do that; I remember htmlview was obsolete 20 years ago... Is there some other mcc to use as html view?




    I think jaca capsulated WebKit for Iris into a mcc, but I'm really no expert in those things. I don't know how much time and effort it is to integrate it into AmRSS. From a users' POV I greatly miss AmRSS.
  • »17.05.24 - 20:07
    Profile
  • MorphOS Developer
    jacadcaps
    Posts: 3020 from 2003/3/5
    From: Canada
    Quote:

    yes, but I am talking about a context where we are in an arexx macro, so users should be free to do whatever they want and so they could make errors without freezing the system. I can't understand why what I can do to replicate the stack check under mos.


    MUI has always required notifications to be set up so that they don't trigger each other. No check can reliably workaround that.

    Quote:

    Is there some other mcc to use as html view?


    WebKit could be embedded in other apps, but only if they're written in ObjectiveC-MUI.
  • »18.05.24 - 02:37
    Profile Visit Website
  • Butterfly
    Butterfly
    alfie
    Posts: 89 from 2005/3/25
    From: Italy
    Quote:


    No check can reliably workaround that.



    Sorry If I am pedantic:

    Code:

    #define STACK (getreg(REG_A7)-(ULONG)(((struct Task *)(FindTask(NULL)))->tc_SPLower))

    static ULONG
    mSets(struct IClass *cl,Object *obj,struct opSet *msg)
    {
    struct RxMUIData *data = INST_DATA(cl,obj);

    return (data->ol && STACK<data->ol->header->minssize) ? 0 : DoSuperMethodA(cl,obj,(APTR)msg);
    }


    Worked for ages on classic. So what may I do to replicate that on mos?

    Quote:


    WebKit could be embedded in other apps, but only if they're written in ObjectiveC-MUI.


    Arg, that's a pity.
  • »18.05.24 - 08:13
    Profile Visit Website
  • MorphOS Developer
    jacadcaps
    Posts: 3020 from 2003/3/5
    From: Canada
    @alfie

    Code:
    (data->ol && STACK<data->ol->header->minssize)


    Not sure what this is supposed to do exactly, but you could simply have a counter variable in your instance data and check that rather than make assumptions on stack layout.
  • »19.05.24 - 00:18
    Profile Visit Website
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    Georg
    Posts: 109 from 2004/4/7
    Quote:

    jacadcaps wrote:
    MUI has always required notifications to be set up so that they don't trigger each other.



    Not really. There's a lot of code/programs which rely on not really documented TAG_IGNORE poking in internal MUI classes (but also some external ones) where in OM_SET they do "if (new_value == old_value) tag->ti_Tag = TAG_IGNORE).

    Quote:


    No check can reliably workaround that.



    AROS MUI (Zune) internally detects notification loops in very simple way. The notfication nodes (each object has a list of notifications set up on it) has an "active" flag. When a notification is fired:

    Code:

    nnode->active = TRUE;
    DoMethod(destobj, ...);
    nnode->active = FALSE;


    But before doing that, it checks if active is already TRUE. If so, it has detected notification loops and aborts.

    I wonder what would break if MUI did that internally, too? As last resort notification-loop-prevention. One issue is that if a new program would rely on that, it would break in an older version of MUI that did not yet do that. Also it is not 100 % alternative to stupid TAG_IGNORE poking, because behaviour can still be slightly different, so it would still not allow you to get rid of stupid TAG_IGNORE poking in internal or external classes.
  • »19.05.24 - 08:11
    Profile
  • Butterfly
    Butterfly
    alfie
    Posts: 89 from 2005/3/25
    From: Italy
    The problem is that in the example above the TAG_IGNORE trick can't be used, because the two objects notify between themselves via triggervalue and nottriggervalue, so the value always changes.

    Ages ago I tried a lot of different approaches to the problem and none actually worked, but the stack check: if the used stack is less than a peculiar value than return 0 and everything should stop, because the OM_SET doesn't reach superclass so a new notification is not triggered.

    It worked fine on 68k, but it doesn't work on MOS: as the available stack goes under 28k (!!!) the loop is unstoppable and I can't see why.

    Now, because for other reasons (mainly to kill all notifications from and to an object when it is dropped) I maintain a notifications list for each object, I could check at notification setup if a loop is introduced, but it would only work if the triggered method is OM_SET. If the triggered method is a generic external class MUIM_DoSomething, I have no way to know if MUIM_DoSomething sets some attribute on the object, so stack check is again the only way.

    If there is something undocumented in MUI so that I could do a
    case attr:
    if (DoMethod(obj,MUIM_IsNotifying,attr)) return 0:
    break;

    where MUIM_IsNotifying returns TRUE if obj is notifying attr, false otherwise

    I would be vary happy :P


    [ Edited by alfie 19.05.2024 - 10:41 ]
  • »19.05.24 - 09:37
    Profile Visit Website
  • Moderator
    Kronos
    Posts: 2257 from 2003/2/24
    Well the stack attempt "worked" on 68k only by accident as just changing the compiler on any of the involved binaries could have given different results.

    Don't know much about RxMUI but a general workaround would be to create a 3rd object (MUIC_Notify) and have both radios notify only to that.
    The notify object would then set the radios with "MUIA_NoNotify,TRUE".
  • »19.05.24 - 10:10
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    Tcheko
    Posts: 518 from 2003/2/25
    From: France
    Quote:

    alfie wrote:
    The problem is that in the example above the TAG_IGNORE trick can't be used, because the two objects notify between themselves via triggervalue and nottriggervalue, so the value always changes.

    Ages ago I tried a lot of different approaches to the problem and none actually worked, but the stack check: if the used stack is less than a peculiar value than return 0 and everything should stop, because the OM_SET doesn't reach superclass so a new notification is not triggered.

    It worked fine on 68k, but it doesn't work on MOS: as the available stack goes under 28k (!!!) the loop is unstoppable and I can't see why.

    Now, because for other reasons (mainly to kill all notifications from and to an object when it is dropped) I maintain a notifications list for each object, I could check at notification setup if a loop is introduced, but it would only work if the triggered method is OM_SET. If the triggered method is a generic external class MUIM_DoSomething, I have no way to know if MUIM_DoSomething sets some attribute on the object, so stack check is again the only way.

    If there is something undocumented in MUI so that I could do a
    case attr:
    if (DoMethod(obj,MUIM_IsNotifying,attr)) return 0:
    break;

    where MUIM_IsNotifying returns TRUE if obj is notifying attr, false otherwise

    I would be vary happy :P



    The loop notification is avoided by using a NoNotifySet method. That's the official way to handle such situation as Jaca hinted earlier.

    If this is problematic, subclass a group object and implement an improved logic for updating object states.
    Quelque soit le chemin que tu prendras dans la vie, sache que tu auras des ampoules aux pieds.
    -------
    I need to practice my Kung Fu.
  • »19.05.24 - 10:19
    Profile Visit Website
  • Butterfly
    Butterfly
    alfie
    Posts: 89 from 2005/3/25
    From: Italy
    Quote:

    Kronos wrote:
    Well the stack attempt "worked" on 68k only by accident as just changing the compiler on any of the involved binaries could have given different results.



    It was not by accident, it is just how the stack works on amiga 68k. Because of different types of binaries are involved it doesn't work anymore, hence the question.




    [ Edited by alfie 19.05.2024 - 11:43 ]
  • »19.05.24 - 10:41
    Profile Visit Website
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    polluks
    Posts: 789 from 2007/10/23
    From: Gelsenkirchen,...
    @alfie
    Welcome back! We still are looking for innovative developers :-)
    Pegasos II G4: MorphOS 3.9, Zalman M220W · iMac G5 12,1 17", MorphOS 3.18
    Power Mac G3: OSX 10.3 · PowerBook 5,8: OSX 10.5, MorphOS 3.18
  • »19.05.24 - 22:20
    Profile
  • Butterfly
    Butterfly
    alfie
    Posts: 89 from 2005/3/25
    From: Italy
    Quote:

    Georg wrote:
    Are all classes subclassed by RxMUI (to do that stack check, and maybe other stuff)?

    If so maybe just create your own notification system (similiar to https://github.com/aros-development-team/AROS/blob/master/workbench/libs/muimaster/classes/notify.c) and bypass the MUI one.



    That's brilliant! Thanks.

    Alas, I could not do that, but your suggestion inspired a very simple solution I can't believe I didn't found before.

    Quote:

    polluks wrote:
    @alfie
    Welcome back! We still are looking for innovative developers :-)


    Thanks, but after your twenties the probability to be innovative is 0 :P


    P.S.
    In the last years many asked me to release the source of RxMUI. When I tried to create a sane archive, I deleted a lot of files :P

    Anyway, here they are http://alfie.altervista.org/rxmui/index.html .
  • »22.05.24 - 17:56
    Profile Visit Website