An application with an M main cannot call external calls in Go, Rust, or threaded-C
Final Release Note
Description
When YottaDB starts up, in gtm_main.c YottaDB sets the noThreadAPI_active to TRUE and simpleThreadAPI_active to FALSE uniformly such that any calls to threaded API routines fail because the execution mode is set to non-threaded mode.
The current workaround is to create a C, Go or Rust main program that then uses call-ins to call M code. If the first call is a threaded call, that sets the execution mode to threaded mode so the M code could then call-out to Go, Rust or threaded C code as it chose to do so.
There are a couple ways to approach this. We could have YAEV (yet another environment variable) that specifies a mode to set when an M main starts. The M code itself doesn't care which mode is set as it calls all the lower level DB interfaces directly. But as I think about it, say an M main called a Go external call which spun off some goroutines running in other threads (similar examples in Rust or C possible) but then returned to the M main before those spun off goroutines finished. That means we could have the M code and the Go code doing simultaneous operations which would be a no-no so this needs some more thought.
Note a VIEW command could also be used to switch back and forth between the modes. or perhaps the mode is switched to threaded access for the duration that the external call is running but is switched back to non-threaded mode when that returns. That would prevent any leftover goroutines or threads from the external call from doing anything until the M code made another external call.
Anyway, food for thought and discussion.