Broadcasting user messages

In the PRM (vol. 3 p. 196-198 in the printed edition) the explanation of Wimp_SendMessage says that acknowledging (with event code 19) a broadcast message will cause it not to be sent on to other tasks. What appears to be the case, but is not stated anywhere, is that replying to a broadcast message, by setting +12 of the block to the value received in +8, also seems to stop a broadcast message from being passed on to any other tasks.

The wiki article is rather brief and a little misleading in its explanation of event code 19. I might try to enhance it a bit!

I had wanted to be able to broadcast a message, and have more than one other application receive it and reply to it quoting the right reference. Is this not actually possible? Apologies if this is actually documented somewhere. I’m rather surprised I have never encountered this problem before.

Sounds like you should be sending a normal type 17 message to all tasks rather than using a type 18 broadcast, if it isn’t intended for a single task to respond to it.

That may be the problem. I will investigate further.

The PRM is far from clear as to what happens to broadcast messages. It only says “If you acknowledge a broadcast message, it is not passed on to any other tasks.” That’s in the paragraph about event code 19.

It does not say “if you reply to a broadcast message, quoting the my_ref of the message in the your_ref field, it is not passed on to any other tasks”. Nor does it say the behaviour differs if the message was sent with code 17 rather than 18.

I will do some experiments.

The PRM is far from clear as to what happens to broadcast messages.

It’s actually pretty clear, you’re just looking in the wrong place, it’s the paragraph above talking about receiving a recorded message. ;)

My emphasis.

User_Message_Recorded 18
The block has the same format as that described above under User_Message. The interpretation of the message action is the same, so the way in which the receiving task handles these two types should be identical. However, the way the Wimp responds differs if the message is not acknowledged.
The receiving task can acknowledge the message by calling Wimp_SendMessage with the event code User_Message_Acknowledge (19) and the your_ref field set to the my_ref of the original. This will prevent the sender from receiving its original message back from the Wimp with the event type 19.
Another way to acknowledge a message (and prevent the Wimp returning it to the sender) is to send a reply message using event code User_Message or User_Message_Acknowledge, again with the your_ref field set to the original message’s my_ref.
Both types of acknowledgement must take place before the next call to Wimp_Poll.

The wiki article is rather brief and a little misleading in its explanation of event code 19.

As with the PRM, the detail isn’t in the overview of messages, it’s in the specifics of recorded messages.

https://www.riscosopen.org/wiki/documentation/show/User_Message_Recorded

It’s actually pretty clear

I think if it’s easy to misunderstand then it’s not clear!

In particular, I cannot see anywhere in the PRM a clear explanation of what happens when you reply to a broadcast message. Page 3-197 distinguishes acknowledging and replying to messages:

There are three variations, depending on the event code in R0 on entry. The first two, User_Message and User_Message_Recorded (17 and 18), send a message to the destination task(s). The latter expects the message to be acknowledged or replied to, and if it isn’t the Wimp returns the message to the sender.

The next paragraph explains that User_Message_Acknowledge is to be used to acknowledge the receipt of a message without generating an event at the destination task. It concludes:

If you acknowledge a broadcast message, it is not passed on to any other tasks.

As far as I can see, the PRM does not say anywhere that replying to a broadcast message prevents it being passed to other tasks. From my test this morning, it appears to do so whether the original message was sent recorded (18) or not (17). Druck’s reply above implies he thought the behaviour differed, so I think this is another vote for the PRM being unclear. After all, you would have no reason to acknowledge a plain User_Message, so it would be reasonable to assume that the sentence about broadcast messages not being passed round other tasks would not apply.

The explanation of User_Message under the entry for Wimp_Poll, page 3-127, says that the event is returned “when another task has sent a message to the current task, to one of its windows, or to all tasks using a broadcast message”. There’s no suggestion that the task might be able to prevent the message being passed round the remaining tasks. Nor does it mention it under User_Message_Recorded. The only mention of this effect seems to be under Wimp_SendMessage.

I can see that it’s much simpler for the Wimp to work the way it appears to. It’s just annoying that it has never come to my attention before, and that we designed a message protocol on the assumption that broadcast unrecorded messages did actually reach all tasks.

a clear explanation of what happens when you reply to a broadcast message.

The part that I quoted. Replying to the message is treated as an acknowledgement.

As far as I can see, the PRM does not say anywhere that replying to a broadcast message prevents it being passed to other tasks.

It is implied in the mechanism. A message that is broadcast is passed around until something acknowledges the message or there are no more tasks. Replying is the same as acknowledging.
That’s why some informational messages, such as Message_ModeChange specify that the message should not be acknowledged.

As far as I can see, the PRM does not say anywhere that replying to a broadcast message prevents it being passed to other tasks.

Yes, it does. It says “If you acknowledge a broadcast message, it is not passed on to any other tasks.” under the description of Wimp_SendMessage.
bq. The only mention of this effect seems to be under Wimp_SendMessage.

Whuh? “The PRM doesn’t say anywhere” and “it mentions it here” are mutually exclusive, incompatible, and make my head hurt.

It is documented, and it is (as I point out) why some messages say not to acknowledge them.

Honestly, a line to clarify in the descriptions of acknowledging messages in the bit about poll event 18 wouldn’t have gone amiss either, but the PRM authors clearly felt that a brief mention was enough.

I also don’t get why there are two ways to acknowledge a message. Was this a RISC OS 2 bodge or something? Unfortunately BlackLog doesn’t go back to Arthurian Legend so I can’t see when messages were added to the Wimp and how this developed.
Especially given that replying is treated as an acknowledgement, which means the sending task will see no message come back via event 19. It does not see a reply.

At any rate, it’s all documented. It’s just a big game of join the dots.

After all, you would have no reason to acknowledge a plain User_Message

That’s completely understandable. I think the only difference between 17 (regular message) and 18 (recorded message) is not in how the message transmission is handled, but in what happens at the end…whether the message is dropped or if it is bounced back to the sender as a failure.

I’m on my phone, and just noticed Stranger Things #4 is now out, so I won’t go poking around the maze of twisty passages that is the Wimp’s source.

and that we designed a message protocol on the assumption that broadcast unrecorded messages did actually reach all tasks.

Well, the obvious question is that if it is a broadcast regular message, why is anything trying to acknowledge it?
Change your spec to say “this message should not be acknowledged”, and if nothing does it’ll be passed around as expected.

Thanks for all your efforts, Rick, but you’ve missed the point I was trying to make. Perhaps you cannot see the bold text? The sentence which explains that acknowledging a broadcast message prevents it being seen by other tasks is at the end of the paragraph which explains how to use User_Message_Acknowledge. The previous paragraph explains that with event code 18 it expects a reply or an acknowledgement.

It is quite possible to understand from this that replying and acknowledging are two different things, and that only User_Message_Acknowledge would stop the passing of broadcast messages to other tasks.

Page 3-128, which you quoted above, implies that replying is seen as another way to acknowledge, but that part of the PRM does not mention the effect on broadcast messages, only that acknowledging presents the message being returned to the sender, so it’s easy to miss.

As you say, it is all in there if you join the dots, or if you somehow have an affinity or instinct for how the mechanism is implemented, but that brings me back to my original point, that the PRM is not clear about what happens. A “big game of join the dots” is not necessarily adequate documentation! In particular on page 128 it is suggested that replying is a form of acknowledgement, and on page 197 it is implied that it is something different.

Well, the obvious question is that if it is a broadcast regular message, why is anything trying to acknowledge it? Change your spec to say “this message should not be acknowledged”, and if nothing does it’ll be passed around as expected.

The problem is that the message being broadcast, Message_GeoData_DescribeDatasets, is supposed to go round all tasks to discover what geocoded datasets are available from applications which are running. The applications are supposed to reply with potentially multiple instances of Message_GeoData_DatasetDetails. This all worked fine when we had only released one application providing datasets — Recce — but now BusWatch is released, the reply from one prevents RiscOSM discovering the other! We’re going to have to do a bit of a redesign, as there seems to be no way to get a message round all tasks via broadcast and also allow them to reply. This is a bit of a nuisance, as the mapping application, RiscOSM, does not just seek to discover datasets. It sends information about what area of the world it is interested in. That means that the information sought has a context, and that was most easily expressed as a reply to the message.

That means that the information sought has a context, and that was most easily expressed as a reply to the message.

I wonder if this sort of thing is why !Help uses two different messages – one for requesting help and one for sending info back?

I think you’ll need to do similar with your messages. Treat the “what’s available?” as a request for information, and those who have data available can respond. If you need context, you could always reserve a word or two in the structure to copy that context.

Plus, doing it this way allows for a new data source to fire off an announcement when it starts up to say “hey, I’m here”. ;)

The sentence which explains that acknowledging a broadcast message prevents it being seen by other tasks is at the end of the paragraph which explains how to use User_Message_Acknowledge. The previous paragraph explains that with event code 18 it expects a reply or an acknowledgement. It is quite possible to understand from this that replying and acknowledging are two different things.

My guess is that it’s written from a ‘human perspective’: Obviously in real life you can’t respond to something without acknowledging it (you can’t ignore and not ignore something at the same time). However, I also agree that a note to that effect wouldn’t go amiss.

I think you’ll need to do similar with your messages. Treat the “what’s available?” as a request for information, and those who have data available can respond. Plus, doing it this way allows for a new data source to fire off an announcement when it starts up to say “hey, I’m here”. ;)

Yes, already doing this actually.

If you need context, you could always reserve a word or two in the structure to copy that context.

That’s the challenge when the software is already out there and both ends would need altering. We’ll have to think about how much the context matters. As we’ve published the protocol there may be other software out there we don’t yet know about.

Maybe instead of sending a broadcast, you need to list the all tasks running, then send a directed message to each in turn.

Maybe instead of sending a broadcast, you need to list the all tasks running, then send a directed message to each in turn.

That could be a good quick fix for RiscOSM while we work out how to redesign the protocol.

Wasn’t that what I said in the 2nd post?

Sorry, I didn’t realise what you meant by “to all tasks”. I was still thinking you meant broadcast, and so I checked out whether broadcasting as 17 behaved differently from 18.