Unexpected Multitasking BASIC/Moonfish

Somewhat surprised to find that I can access a harddrive attached to my Pi from the Mac, via Moonfish, even with a BASIC program running on the Pi, while it isn’t (explicitly) polling the WIMP.

The program in question polls the WIMP to get its instructions in a text file that you drag and drop onto its icon, then runs for many hours without polling the WIMP, saving files at intervals varying from minutes to hours. It doesn’t (explicitly) poll the WIMP again until it’s made all the files it’s been asked to. Via Moonfish I can see all the files it’s made so far, even while it’s still working on the others. I can even save other files to the hard drive, and read the files the program has already made, and delete things off that hard drive.

How does that work? Uncooperative multitasking by Moonfish, obviously, with interrupts. I’m quite impressed that that’s working.

Another interesting (but possibly not terribly relevant to RISCOS) thing discovered in the course of this, is that looking at the Pi’s harddrive via Moonfish from Mac (Mojave) knows the date and time of creation of the files, from Mac (High Sierra) they’re all reported as Date Created at 01 Jan 2001 at 00:00, with no Date Added.

Network filing systems don’t use the WIMP, it will get callbacks any time the client makes a request over the network.

Indeed, that was what I’d deduced, hence my comment “Uncooperative multitasking by Moonfish”. Indeed, and not just the network filing system, but the hard disc filing system as well, since that’s involved in serving the local hard drive over the network. And they’re not upset by the WIMP, either, which was what surprised me a little, since the local user obviously won’t be using the filing systems other than via the WIMP.

Thankfully we stopped the Window Manager getting its claws in too deeply.

Callbacks are your friend.

Callbacks are your friend.

Evidently! Thank goodness for that.

Next thing is to see whether I can still access the hard drive over the network after some BASIC program has crashed the machine – presumably being in an infinite loop with no escape and no polling won’t stop the callbacks? I can imagine some proper crashes being more thorough though.

Callbacks (normally) only fire when the machine returns to user mode with interrupts enabled. So an infinite loop in user mode is usually fine, but an infinite loop in supervisor mode isn’t.

That makes sense. What the actual processor is capable of (at least up to ARMv7) I’m pretty familiar with – it’s what’s actually built with it I know far less about!