Signals sent to 'this' are not prioritized

[gbatori1]

The Signal sent to this must be prioritized so they should be pushed to the internal queue of a statefull class.

For example in PacketSwitchLeg::ClosingPendingTransaction state sending the remove signal must be priorities. rALF: // generate CallLeg20:'remove' to self; send new CallLeg::remove() to this; C++: // RALF: send new CallLeg::remove() to this; ::eatf::ComponentsLibrary::EATF::eatfImplPkg::CallLeg::remove_event* ralf60remove = new ::eatf::ComponentsLibrary::EATF::eatfImplPkg::CallLeg::remove_event(false);

Parameter of the of the remove_event call must be true instead of false.

[doczir]

In case the target of the send statement is this then the model compiler can be easily adapted, however, if the target is a result of a selection and the resulting object is equal to the this instance then this information cannot be calculated in compile time. Should this case be considered as well?

[gbatori1]

Only the first case is important. If a Signal is sent to this then it should be prioritized.

[doczir]

This issue should be fixed with the latest commit. The current solution is to provide the sender to the generate_event method in which it can determine if the sender is the same as the receiver object. If that is the case, it means the target of the signal is this instance and the signal gets in the queue with the higher priority.This should provide the proper priority for both cases. This also makes the _isInternal field in event unnecessary.

[g2k2c8]

After a telephone discussion with Gábor an agreement was made that the MC should support the "two operation approach", where the MC should generate a separate method for the internal and the external events and the internal one will only be called when the self target is used (and in case a select returns the same object instance as the self would then it should also be scheduled as an external) . However, it should be also noted that this execution semantics was criticized by Akos as a faulty behavior.

[gbatori1]

Just for reading material this is stated in the Signal Priority specification (see in link): The only extension required is for the case of an object sending a signal to itself. In this case, the signal, by default, is sent with the special “self” priority, so that it is dispatched before any signal sent by another object (with a normal user-specifiable priority). The meaning of “sending a signal to itself” is restricted here to an explicit signal send to “this”. That is, a signal send of the form this.S(a1, a2, …) where S is a subtype of PrioritizedSignal and no value is given for the priority attribute, should be interpreted as if it had the form this.S(a1, a2, …, Priority::self) not as having the usual default priority of “general” (though it is not actually allowable to explicitly reference the Priority literal “self” in a user model). However, if a different, user-specifiable priority is explicitly given in a self-directed signal-send, then the signal will be sent with that priority, not the special “self” priority. This “self” priority is not required in the case in which a signal is sent to an arbitrary target that might dynamically evaluate to the sending object, but only if the signal is explicitly sent to “this”. Therefore, it is possible to statically determine a “self-directed send” in the Action Language and set the priority value appropriately in the processing of such an expression.

[abelhegedus]

Priority added for events in master.