I'm looking for guidance for my apps on when to use singleThreaded: true.
Some of my apps declare singleThreaded: true and also serve a UI or API through mappings. On 2.5.2.128, for a single app instance, I observe:
Scheduled handlers and async HTTP callbacks run one at a time.
An endpoint call waits while a scheduled handler or callback is running, and a scheduled job waits while an endpoint is running.
Concurrent endpoint calls to the same instance usually run in parallel. In a few bursts they ran one at a time.
A callback that arrives while an endpoint is running sometimes runs alongside it and sometimes waits.
Q. Are those observations coherent with the platform's design? Or should we expect singleThreaded: true to serialize every method call, regardless of origin?
The idea is to prevent execution of the same app/driver instance's code at all times. I'm inspecting the logic now to see if there are any implementation holes.
I don't know how AI would know, but it suggests that child devices calling parent methods could run in parallel with singleThreaded true, if the child called two methods at the same time, as singleThreaded wouldn't have control over that.
I ran a whole bunch of tests after tripping over an issue. That's the best way to know, and AI can help build and run those tests. If your AI is simply projecting based on its training data, that is far less reliable.
I didn't check the specific scenario you mention, but I will. I hope the answer will be that singleThreaded guards against multiple concurrent child calls.
Correction to my original post: singleThreaded: true does serialize endpoint calls. My use-case sent identical concurrent GETs, and the hub served them from a single execution, which I read as parallel calls. With unique URLs, every entry point I tested ran one at a time, including endpoints, schedules, callbacks, events and child calls into the parent.
Is it intended that concurrent identical GETs to an app endpoint share one execution and response? I will double-check, but looks like a UI with several clients polling the same URL may get the same result for all of them.
Yes, that's correct. The calls would run in the context of the child app. You'll need to have your own concurrency guards in the parent app if that's the use case.
Thanks — that matches how the call executes (on the child's thread), but it doesn't match what we measure. On 2.5.2.133 (also 2.5.1.183 and 2.5.2.129), with singleThreaded: true on the parent, two child devices (or two child apps) calling the same parent method at the same moment never overlapped in 30/30 runs: the second child's call blocked inside parent.method() until the first returned, then started ~2 ms later. The identical parent without the flag overlapped every time. Same result whether the parent was sleeping, CPU-busy, or in a blocking HTTP call. Test and probes available upon request.
Is this serialization something we can rely on, or an implementation detail that might change?
