You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
A callback does not automatically include a different thread (callstack wise)... It can be calling something that then does 'synchronously' call the callback after completion of the connect to continue in the app as the app defines. Looking at the call stack it would show 3(+) levels with the last 3 levels: the app running and calling the connect, connect running and calling the app (callback), the app (callback) running...
A non-blocking connect call would actually store the callback away, return to the app before the connect is completed. Completin of the connect then calls the stored away call back in a next js-activity 'thread'.
Since the connect on these small devices are 'blocking', interrupts become a challenge, especially when it takes some for the connect to come through.
I'm wondering if a software interrupt could be used... in the meantime with a setWatch and a pin... with that pin just being the (sacrificed) pawn to wake up a service routine resolver, latter fireing the execution of the service routine stored (instead of connect storing away the callback at invocation, the callback is put on the interrupt 'stack' / fix pickup location just before invoking the software interrup (yanking the pawn pin).
Instead of going down the HW / setWatch / pin-yanking lane, it could produce an interrupt in the regular Espruino interrupt queue... (which I think Espruino is already doing for all asynchronously handeled callbacks).