I guess I understand what your are saying about reentrance...
I also conclude that the process is to complex and variable to be implemented without memory resources that are exposed to potential GC.
I though still expect/require a modification to existing setWatch() and clearWatch() functions in order to make it transparent for the application whether it is a built-in pin or or an extension-pin (a pin of any sort of portextender):
With these two extensions it is possible to make any watch operation absolutely transparent - for the pin:
Should a)2. - holding on to passed portextender pin object in the internal watch object for any reasons - such as potential memory leak - not be possible, then this alternative is good enough:
The alternative does not support clearWatch() with no arguments, and - from my point of view - this is acceptable, because using clearWatch() with no arguments has anyway its challenges. Still transparent to the pin are:
clearWatch() with no arguments
With the alternative, Espruino has to store nothing about the watch. Non-built-in, portextender pins trigger the redirect of the argument(s) for both .setWatch() and .clearWatch().
For alternative it works also that the portextender object is passed rather than a pin. The portextender object has then to understand .setWatch() and .clearWatch, which could set interrupts for groups of pins. The implementations can even go that far, that .setWatch() can return any custom object deemed useful in the watch life cycle, as long as built-in clearWatch() can detect that passed in 'pin' object is not a built-in pin.
© Espruino, powered by microcosm.
Report a problem