P-1.1.10

[ankushdesai]

Please upgrade to P version 1.1.10 whenever you get a chance.
There is a small change in the semantics of receive in the latest version of P.

In older versions, when a state machine was blocked on a receive statement sending a halt event to that machine would not HALT the machine until the machine received the event it was blocked on (the machine would then halt as it would dequeue the halt event after being unblocked ). In the new semantics, even when a machine is blocked on a receive statement, sending a halt event from any machine would lead to unblocking of that machine and hence halting it. In otherwords, halt event is treated as a special event even in receive statements. This change in semantics is mainly because many users of P wanted a way in which they could halt or crash a P state machine even when its blocked on a receive statement.

Please let me know if you have any questions. Cheers!

[shazqadeer]

@ankushdesai : Thanks for continuing to make P work better for its users.

Regarding this change in semantics, I was wondering if you considered the more drastic change of allowing the behavior you made for halt for any other event that has been installed in the state where the receive was encountered?

It has been a while so I am not sure if my question even makes sense any more in the current state of P :-).

[ankushdesai]

Thanks @shazqadeer, its all inspired from you!

For your suggestion, I am not really sure if that is the desired behavior always. I do understand your proposal and I do feel thats the right choice for receive semantics.

I have not yet gotten a request from a user saying "it would be great if receive inherited the action handlers from the state".
Hence, I am hesitant to make that change, because if we make that change then if the developer wants a way block on all event but X, it cannot use receive to block out Y which is handled in the state.

I think we should wait for multiple users to have this request. But I do see your point and thanks!