When the RUN interpreter encounters a subroutine statement, it first checks to see if it refers to an internal SBR (embedded within the A-Shell executable). If not there, it checks to see if there is a matching SBX loaded into the user's memory, either due to an explicit LOAD operation, MX_USRLOD, or an implicit prior load of the same SBX. If not in memory, a disk search is performed (looking in the current [p,pn], the [p,0] or RUN directory, depending on SBX_RUNDIR option, and the BAS: directory, in that order), and if found, the SBX is loaded into user memory.
If the SBX is already in memory, it can be reused directly without reloading. And any SBX loaded into memory this way will remain in cached in memory for a time, based on available space and usage patterns to avoid the overhead of having to constantly reload it from disk. (This cache feature essentially eliminates the need to pre-load subroutines into memory, an optimization technique that was common in AMOS.) However, one potential problem with the cache mechanism is that in order to use an updated version of an SBX (newly compiled or newly copied to the target system), the old copy of the SBX must first be removed from memory. COMPIL.LIT will automatically do a DEL * to avoid confusion over this detail, but in other cases you would be on your own to remember to do a manual DEL * or else wait an unknown amount of time until the SBX gets flushed out of memory to make room for something else.
As of 5.1.1221, this potential problem is automatically taken care of. When an SBX is called, A-Shell checks to see if the version available on disk is newer than the one in memory, and if so, automatically reloads it from disk. To reduce the overhead of this check to a negligible amount, the test is never performed more often than once per fifteen seconds for any single SBX. In other words, within fifteen seconds of copying a new version of an SBX into the search path, all calls to the SBX will begin using the new version.
Note that the test is not "directional", i.e. it will reload the version on disk if there is any difference in the time stamp (newer or older), so you can roll back to a prior version the same way you update to a newer version.
Warning: The search path used to compare the disk version to the memory version is identical to that used to actually load the routine from disk, i.e. first [p,pn], then [p,0] (or the RUN file location, if SBR=SBX_RUNDIR), and finally BAS:. If you intend to roll out a new version of the SBX and take advantage of the AF_SBXAUTOUPDATE feature, make sure that your new version appears before any older versions in the search path. (And if, for some hard-to-imagine reason, you don't want users to immediately being using an updated SBX, don't copy it into the search path.)
