You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • Ahh, right - that makes a lot more sense!

    Thanks for that - in _jswrap_interface_setTimeoutOrInterval I think there isn't a huge issue because jsvObjectSetChild is null-safe, although the jsvObjectSetChildAndUnLock that it calls could still 'lose' some locks. I'll add a guard in anyway.

    jsvObjectSetChildAndUnLock is a really good spot - thanks! I've just pushed a fix for that.

    It's definitely good practice to check when allocating something like an object but I wouldn't worry about trying to clean up after yourself in the library. When you do 'SetChildAndUnLock(.... jsvNew...)` then memory errors really don't matter at all.

    Espruino should continue working just fine after an out of memory error - and actually the Linux build does have a 'memtest' where it'll just run the tests time after time, slowly decreasing memory so that it can see if anything breaks badly when out of memory happens at different times.

    If a lock is 'leaked' it's not the end of the world. It basically just means that var can't be garbage collected, so it might result in a memory leak - but in many cases it probably won't even be noticed.

About

Avatar for Gordon @Gordon started