SLEEP 1

Occasionally the support desk as part of investigating an issue might ask you to try adding a SLEEP 1 to the code.  Sometimes many years later we find that SLEEP 1 still in the code !

Why me might suggest adding a SLEEP 1 is due to the client-server aspect of the Genero architecture .  You have the runtime of the fglrun process operating on the back-end server and you have the front-end of the gbc.js / gdc.exe / etc running on the front-end workstation/device.  If we suggest adding a SLEEP 1 it is because we suspect something might be executing on the front-end server before the back-end server has completed the previous step or similar.

One that has occurred in a few calls recently is where you have the following …

    ...
    LET uri = ui.Interface.filenameToURI("myimage.png")
    CALL ui.Interface.frontCall("standard", "launchURL", [uri], [])
END MAIN

… the file does not display in the browser because because by the time the front call executes it cannot find the file.  The workaround has been to add a SLEEP 1 like so …

     ...
     LET uri = ui.Interface.filenameToURI("myimage.png")
     CALL ui.Interface.frontCall("standard", "launchURL", [uri], [])
     SLEEP 1
END MAIN

What is occurring is and why adding SLEEP 1 helps is because these steps occur in the following order …

1. The ui.Interface.filenameToUri method creates a symbolic link to the file that is its parameter making it accessible to the application server.
2. An instruction is passed to the front-end to launch the URL (file://gas/…/myimage.png) that is the parameter passed in the front-call.  This is an asynchronous call, the runtime does not wait until the URL is successfully launched.
3. The END MAIN sees the fglrun process end.  In ending, it cleans up after itself and removes any symbolic links that any calls to filenameToUri call have created.
4. The browser has now started and tries to open the URL, only to find that it cannot display the file as the symbolic links that point to the file have been removed…

By adding the SLEEP 1, steps 3 and 4 are reversed (assuming it takes less than one second for the browser to start).  There is now more chance that the tidy up process on the back-end server occurs after the front-end process has successfully launched the URL and not before.

Now you could leave the SLEEP 1 in the code but one day the browser may be slow to start and you may find yourself thinking that a SLEEP 2 or SLEEP 3 is required.

In the scenario above, what we typically found is that the reason the END MAIN was there is because the developer has a small standalone program with a name like “view_file” and a usage RUN fglrun view_file.42r filename.  The better solution rather than having a small standalone program to view a file would be to add a function into your library to view a file.  Now when the front-call executes and the browser goes to display the file, the calling program is still likely to be running and not deleted the symbolic links.

This thought process should apply elsewhere you find yourself adding a SLEEP 1.  Why I am needing to add a SLEEP 1? what can I configure or do differently that is perhaps more mainstream that negates the need to add this SLEEP 1?  What am I expecting to have been executed that has perhaps not been.