Inline function triggered by a callback = execution timeout
-
Hey there,
since the recent commits every time I call an inline function triggered by a callback (e.g. download finished) it's giving me execution timeout when I push values into an array in a for loop in that inline function.Use case for example: update a list of the files already downloaded after a download is complete.
It was never a problem before and I think it's also no problem in a compiled plugin but I can't really test the flow inside hise anymore so I'm wondering if this is here now for a reason / a bug / or if this needs to be handled differently now.
-
ok seems to work if I get the array out of the inline function (not local) and declare it as reg. (which seems a bit unnecessary as I donÄt need it outside of the function)no it didn't ;)
-
@ps said in Inline function triggered by a callback = execution timeout:
Hey there,
since the recent commits every time I call an inline function triggered by a callback (e.g. download finished) it's giving me execution timeout when I push values into an array in a for loop in that inline function.Use case for example: update a list of the files already downloaded after a download is complete.
It was never a problem before and I think it's also no problem in a compiled plugin but I can't really test the flow inside hise anymore so I'm wondering if this is here now for a reason / a bug / or if this needs to be handled differently now.
Yep I can confirm this - its happening all over the place for me...for example:
I open a dialog to select a folder - then in the function try and findFiles in that folder - then I get execution timeouts happening further into the code...In my case it seems to be about whats loaded in the OS cache..I select a folder - and I time out - I retry using the same folder and it works..
-
@Lindon in the meantime I also figured that this is highly related to the FindFiles function on my end .
Also the cache could be an interesting find cause when I freshly open HISE and load the preset it works for the first time I think.Besides of the timeout the "Inline functions can't be called recursively" warning is going crazy here as well.
-
Yes the problem is that if you hit the timeout execution the inline function can't clean up after itself and thus it will think it is called recursively every time you call it normally.
I also experienced the timeout issue, but if one of you can make a minimal example that reliable causes the timeout to occur, it would speed up the fixing process.
-
@Christoph-Hart said in Inline function triggered by a callback = execution timeout:
Yes the problem is that if you hit the timeout execution the inline function can't clean up after itself and thus it will think it is called recursively every time you call it normally.
I also experienced the timeout issue, but if one of you can make a minimal example that reliable causes the timeout to occur, it would speed up the fixing process.
I've tried - but it wont do it - however I have made a version that calls a timer and executes the .findFiles from there - If I set the time to 2000 it seems to work reliably(..on my machine) -- not sure that helps resolve the problem any....
-
@Lindon damnit - no it doenst...
-
@Christoph-Hart ok i was trying to recreate it in a smaller snippet and obviously no problems - no matter how hard I pushed it...
At some point I had basically everything recreated and there was only one thing missing - a panel with a paint routine... And voila - Execution timed-out.
And I'm not talking about a paint routine related to the functions, external repaint or anything. Just adding:
const var Panel1 = Content.getComponent("Panel1"); Panel1.setPaintRoutine(function(g) { g.drawAlignedText("Test", [0,0,this.getWidth(),this.getHeight()], "centred"); });
to the script already caused it.
-
@ps That paint routine alone isn't causing the issue, keep trying to narrow it down.
-
@d-healey I think he's saying that the function works fine, then adding a completely unrelated paint routine breaks the function....but adding an unrelated paint routine to my simple example doesn't break it....
-
@Lindon But does adding anything else totally unrelated also break it... the paint routine might be a red herring.
Since the paint routine on its own doesn't cause an issue what else can be removed from his project that will make the issue go away.
-
OK. I'm not gonna say that this makes any logical sense but here we go:
This is the most simple version I could make to get the timeout - If I comment out the Paint Routine no timeout - so there has to be a relation even if it's very abstract.EDIT: The execution timeout will happen at the for loop if the paint routine is in the code just fyi
/// FUNCTION CALLING A JSON + RESPONSE TRIGGERS ANOTHER INLINE FUNCTION inline function loadjsn() { Server.setBaseURL("https://something.com"); Server.callWithGET("/something", "", function(status, response) { test(); }); } loadjsn(); /// HERE WE NEED THE FIND FILES FUNCTION (IT WAS JUST A COUPLE FILES ON AN SSD) + FOR LOOP THAT PUSHES INTO THE ARRAY IS NEEDED AS WELL inline function test() { local files = FileSystem.findFiles(FileSystem.getFolder(FileSystem.Samples),"*.wav",1); local array = []; for (x in files) array.push(x.toString(1)); Console.print(array.length); } ///COMPLETELY UNRELATED PAINT ROUTINE - NO TIMEOUT WHEN COMMENTED OUT const var Panel1 = Content.getComponent("Panel1"); Panel1.setPaintRoutine(function(g) { g.drawAlignedText("Test", [0,0,this.getWidth(),this.getHeight()], "centred"); });
-
@ps What happens if instead of calling
loadjsn();
you calltest();
? So you bypass the server call entirely.Also what happens if you change the order of the paint routine and
loadjsn()
? since they are both triggering in on init.Also I'd avoid calling your Array array - I don't think it will cause a problem but it's not usually a good idea to give a variable the name of a type.
-
@d-healey as said if I skip any of the parts I don't get the timeout - it only happens if the function get's called by a callback and contains FindFiles and for loop.
The naming in my example here should not reflect my usual naming conventions ;) -
@d-healey the order unfortunately doesn't make a difference.
-
@ps I need a snippet I can test on my system, can you share the real server endpoints? Do you need to use findFiles or can you put some dummy data in there?
-
@d-healey you can use it exactly this way - the actual response doesn't matter, I had real endpoints before but it also happens exactly that way with a dummy endpoint the crucial factor seems to be that the callback is executing it - just change the FindFiles to something where it can actually find files on your system and it should happen. (Can only speak for MacOs right now)
EDIT: If it doesn't find files - no timeout
-
@ps Ok I'll play around with it
-
@ps I pasted your code, pointed findFiles to a folder containing 3 wav files, hit compile, no issues. Might be a MacOS only thing. I'll test on my Mac.
-
@d-healey --no this problem with findFiles is happening on my Windows machine...