pxt: Pause in "on start" does not delay "forever" loops?

microbit.org-ticket: 2187

Aren’t the “forever” loops meant to start running after the “on start” blocks have finished?

If we need to initialise something before it can be used (like neopixels or game sprites), the “on start” is usually the preferred place to do that, but if the “forever” loops are declared before the “on start” code, and then the main fibre sleeps, you could have a race condition like in the following example:

microbit-screenshot

This program produces the following error and crashes the emulator:

Program Error: r.isRef is not a function

Hex file with this minimalist example: issue.zip

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 36 (24 by maintainers)

Most upvoted comments

Thank you very much for your responses. Adding a flag to indicate “readiness” is certainly a workaround, but it cannot be denied that the current implementation is not really intuitive. The user would expect the application to “pause” for an amount of time, and instead other parts of the program run earlier.

The user has no way to know that when a “pause” block is used within “on start”, it will automatically trigger processing of the other fibers (in this case the “forever” blocks). So they would have no way to know that the would need to create a “ready” flag to avoid this issue. On top of that, the exposed error “Program Error: r.isRef is not a function” is cryptic and gives absolutely no indication of where the issue might lie.

I understand that forever being a background fibre is a design decision, but is it done by design that the pause block on the “on start” will trigger them? This behavior would be very difficult to predict unless the user has a very good knowledge of the internal micro:bit runtime implementation.

microbit-carlos on Jul 3, 2017

I would expect - trying to think from a non expert POV - that if I programmed on start it would be the first thing to run, and it would complete before forever - which is the only other ‘code’ area I write - starts. I am not sure how a non expert would view hardware driven events (on shake etc). I think that it would be reasonable to expect them to ‘just work’. This code:

shakybreaky

Runs fine in the simulator, but occasionally crashes on a real microbit. It can be made to crash by shaking the microbit as you release the reset button - not sure how ‘real world’ that is. Once crashed the reset button does not bring it back - only a power cycle will.

DaveAtKitronik on Sep 14, 2017

Thanks for the follow up @abchatra. I’m just wondering if it’s there any advantage to run any fibre before on start finishes? Just from a user perspective, I would expect it to run first and finish before anything else starts running. And as it currently stands, other event like the mentioned onShake would only work before the on start finishes if the user happens to include a pause block, which is a big “if”.

As a non-preemtive scheduler I understand the need to protect against infinite loops (without a sleep) to block other fibers/events, but right now there is no protection for that use-case, so what is the advantage of declaring the fibres before on start?

microbit-carlos on Jul 4, 2017