An interesting development regarding preemption in the Desktop

I have done a thing that allows this to happen:

I am equivocal about whether one should, just because one can.

Looks impressive that you can still interact with the OS while there is a dialog message displayed, what are the implications of this going forward?

Are you looking at trying to achieve what WIMP2 attempted to do, pre-emptive multitasking?

Looks impressive that you can still interact with the OS while there is a dialog message displayed

Much more impressive is how it came to be, the ability to suspend the usual round robin behaviour of DataLoad messages. That is impressive.

Further down nemo’s feed: “We and our 870 partners”.
Only three digits? Amateur! ;)
Try this.

CALL foo;1,2,“like SYS” TO bar%,baz%,qux$

Given the code is there (for SYS), it’s a shame CALL doesn’t work like that.

Yup, InitStore is the nuke it from space option. Use carefully. [you haven’t used RISC OS until you’ve stiffed the machine with a “hmm, I wonder what this does”, followed by the dawning realisation that, no, you didn’t save that Edit file first…]

Looks impressive that you can still interact with the OS while there is a dialog message displayed

WimpLog is capable of that, this probably does a bit more, with less.

I’m used to just experiencing all dialog messages basically holding your cursor to ransom until you confirm the message while on RiscOS

the usual round robin behaviour of DataLoad messages

DataOpen actually, which is harder – it’s a broadcast.

WIMP2

I did use WIMP2 at the time, but Niall’s design required a message-handling thread (cooperative) in addition to the preempted thread. As precisely no software was actually written like that, Andrew Teirney’s patch supplied a generic one for all apps, which didn’t work very well and was buggy.

This is a different approach which can be implemented by a Filter on any app, queuing events for the app to deal with when it’s no longer busy. But that strategy is absolutely at odds with the way that broadcast messages, Wimp scheduling and many desktop protocols work. So solving the message wrangling is the difficult bit (preemption is easy – even TaskWindow does that, and it’s rubbish).

I’ve paused DataSave/DataSaveAck/DataLoad/DataLoadAck handshakes indefinitely before (that can be done in a standard Wimp). But broadcast messages have long been the problem. This modest upgrade to the capabilities of Wimp_SendMessage is just enough for a preemption filter to handle broadcast messages in an acceptable way – i.e. with a small but user-controllable delay if there’s a busy task on the message’s path.

interact with the OS

The crucial point is that the app in question has not yet called Wimp_Poll, but has been preempted by a wrapper. That then calls Wimp_Poll and queues anything that comes the app’s way… But while it’s acceptable (to one degree) for clicks in that app’s windows to be delayed, it is not acceptable for a double-click on an unrelated filetype in a Filer window to also be held to ransom by the busy/broken task. The good-citizen filter would therefore pop up this dialog so the user can decide what to do.

Obviously if the busy task finished what it was doing while this dialog was open, it would immediately disappear. (And less obviously, clicking Quit would cut the app off from messaging and events, but otherwise would be required to allow the task to carry on running until it finally gets to Wimp_Poll, at which point it would receive the Poll Event 0.

Mind you, my TaskManager has sharper teeth than the standard one:

Yup, InitStore is the nuke it from space option

I am quite proud that nemoBasic gracefully quits without stiffing the machine. And on that note, a comment during the edifying TWimp presentation (I keep writing Twimp) made me realise that SYS"summat"TOa$ quite happily dereferences R0 regardless of value. So I’ve modified nemoBasic to view 0/-1 as an empty string, and anything lower than the scratch space as “Too low a value for $”.

37 years late.

BTW The SendMessage polishing also enables me to implement what I believe is the first RISC OS functionality suggested by an AI.

That’s a long story, but the feature is this: Wimp message registration:

Apps could document in their !Boot the Wimp messages they are primarily designed to handle, such that the Wimp can launch an app automatically if a broadcast message isn’t handled, and having launched it send the exact same message again to that one app (such that the sender will not be aware that anything novel has happened).

Honestly, that’s such a good idea I wish I’d thought of it. But I didn’t. A machine did.

This is probably how Skynet happens.

e.g. A task broadcasts a StrongHelp_Help message; StrongHelp isn’t running; Wimp runs StrongHelp; sends it the very same message; task doesn’t have to know how to find and launch StrongHelp, the message Just Works™.

Also, the various warning sprites in my OS are actual UK road signs, and the one in that dialog is this, which I absolutely love and could not be more apt:

As usual AI solving a problem which doesn’t exist. As far as the DataOpen broadcast is concerned the Wimp already knows the fallback of the application to load from the file type aliases. The problem that actually needs solving in a pre-emptive Wimp is if that application is already loaded and busy when a broadcast occurs, and only supports a single instantiation.

the first RISC OS functionality suggested by an AI.

Oh, and you were doing so well.

This is probably how Skynet happens.

Artificial Idiocy is nowhere near smart enough for that. There’s a better parable, it involves paperclips. That’s how we’ll meet our demise.

which didn’t work very well and was buggy.

Given that it was a glorious hack, the system actually worked remarkably well. It was definitely something that I felt should have been explored in more detail.

I also think that a cheap and cheerful extension to the Wimp is a set of SWIs to denote “you can safely preempt me here” and undoing that, so when an application is doing something that takes a while (think of ChangeFSI), it can say “just handle the multitasking for me”. It’ll be mute and blind (no clicks, no messages) but the rest of the desktop will continue. It should work fairly well so long as the app doesn’t take forever to do its thing.

The main problem I had with Wimp2 was maybe due to simplicity or maybe the politics of the author (but probably a bit of both) meant that everything was degraded to a RISC OS 2 style Wimp Initialise. So the benefits of giving a list of messages that the app is interested in was lost.

preemption is easy – even TaskWindow does that

And how much scary stuff is in there just to try to stop it from exploding messily? ;)

The problem that actually needs solving in a pre-emptive Wimp is if that application is already loaded and busy when a broadcast occurs, and only supports a single instantiation.

I think it’s up to the app to handle this problem, either by doing nothing if it’s already loaded or by displaying a message.

To return to the question of messages or events, the use of filter can be interesting. There is a use with the modules of the ToolBox.
It’s just a question!

I included the example of StrongHelp precisely because I knew some contrarian would purposefully try to misunderstand, so I’m delighted that the rod twitched.

The problem that actually needs solving in a pre-emptive Wimp is if that application is already loaded and busy when a broadcast occurs, and only supports a single instantiation.

Yup, you really didn’t read the post at all.

The message registration feature came out of a long discussion with an AI regarding the relative merits of Android’s Intents (with which it was entirely familiar) and RISC OS Wimp messages (of which it knew little, originally). Feeding it nothing but information from the PRMs, it came to the conclusion that Wimp Messages were superior to Android intents because of the unique references, the chains of references forming protocols, and the recorded ‘bounce’. All of which it decided would lead to richer inter-task communication than was possible in Android.

However, it noted that one advantage Android has is that Intents are registered in App Manifests, so firing off an Intent will cause an app to be run if it isn’t already running. The AI suggested that this was superior to RISC OS where the sender of a bounced message is required to know how to launch the default app that could deal with the message, and than resend that message itself.

I thought about it for 0.02s and realised it was completely right, as can anyone else with half a brain. I’m interested in good ideas, not who had them.

And bifurcating again, I’m thinking (tangentially) that there ought to be an OS_USRCallBack SWI. A prioritised one with a dedicated stack. I digress.

“you can safely preempt me here”

And if we’re writing new code we could have a separate message handling thread and oh we’ve invented Wimp2 again. The more difficult question is “Can we meaningfully preempt ancient programs without breaking them, other tasks, the UX or the OS?”. As has been discussed on other occasions, you really can’t preempt a Redraw event unless you have a compositing window manager, but almost anything else should be doable.

Anyway, preemption is not an urgent need for me, but I’m grateful to Paolo for setting my mind to the problem. A more powerful SendMessage has lots of other uses too, and I suspect I’ll be doing the Message Registration thing soon.

where the sender of a bounced message is required to know how to launch the default app

If the message relates to a file type, one can simply look at the run action registered for that sort of file? I think this is what the URL action does if nothing picks up on the message…?

And if we’re writing new code we could have a separate message handling thread

…that works in BASIC?
Sorry, that works in our bog standard boring BASIC? ;)