What Fiberless Operation Means to your Application

When AutoCAD is running without fibers, it has only one native code stack at its disposal in its main thread. A number of changes are necessary to the perform the same control transitions made by fiber switching.

The structural control flow changes are as follows:

1. Since the acedCommand() and acedCmd() functionality of switching stacks is no longer available ($FIBERWORLD is 0; both return RTERROR), new functions are provided to allow one to transfer control by pushing more native code onto the stack (subroutine style: acedCommandS() and acedCmdS()) or by returning off the call stack after queueing a message to the logic that will then be executed (coroutine style: acedCommandC() and acedCmdC()).
2. The LISP (command) function is still supported by using acedCommandC(). It causes LISP to save its relevant native call stack state in heap-based structures and return to AutoCAD to allow token processing; it is then re-invoked and its native call stack restored. For the main body of LISP applications, there should be no apparent difference in behavior. However, *error* function overrides can no longer use (command) due to internal limitations in the involved support logic. In most cases, the best alternative will be to convert such uses of (command) to (command-s). (command-s) is a new function introduced as part of the migration path. It requires that token sequences represent complete commands (from start to finish) and does not currently support any user interaction; it runs entirely on the command processor tokens supplied to it. (command-s) usage is recommended  even where not required, as it is significantly faster than a comparable call to (command). It is possible to use (command) from *error* if absolutely necessary, but it is complicated and not at all recommended.
3. The logic previously executed in the application context (“session fiber”) is now either always active as the shallowest section of the call stack, or is invoked by direct subroutine calls from logic that used to run in any document fiber when polling for new system input.
4. The distinction between “application context” and “document context” remains, as manifested in the return value of AcApDocManager::isApplicationContext, but the application context is now “switched to” by “returning out of” the document context logic.
5. Switching or deleting documents is no longer performed synchronously from function calls while AcApDocManager::isApplicationContext() is false; the system completes such actions after control returns to the application context.