when using wasi reactor ( ideal for calling gameloop repeatdly instead of being stuck in main() )
_start vanishes
globals init go into (should be added) to _initializer() actually go in main() but that's just Nim compiler begin funny with reactor model ( should be harmless according to nim lang-dev channel )
wasmtime automatically call _initializer, and then invoke is used to call any exported function
problem:
if not calling main(), gc is probably not active and modules globals are not setup. There is possible undefined behaviour.
- setup can be done manually ( think PyInit_ )
but that may not starting GC and complete NiMain routines
=> but bamboo sample works
when defined(wasi):
proc initialize(argc: cint, args: ptr UncheckedArray[cstring], env: ptr UncheckedArray[cstring]): int {.importc: "main".}
proc setup() : void {.exportC:"setup".} =
when defined(wasi):
discard initialize(0, nil,nil)
echo "_initialized"
discard
# bamboo sample code here
-
when calling manually main() to complete _initializer job, with gc inactive
=> bamboo sample works
-
when calling manually main() to complete _initializer job, with gc( arc/orc ) active.
=> bamboo sample crashes.
-
normal expected way does not work when GC is active after main was called that line does not pass, usually with cryptic traces : it was hard to locate.
|
var acceptorDict = addr this.callbacks.mgetOrPut(event, Table[int, proc (args: openArray[EventParameter])]()) |
neither taskMgr.add later because same model.
- actual less worse option :
removing calls to .accept or .add makes a running sample with a GC and stepping like that
proc step*(this: ShowBase) =
eventMgr.doEvents()
discard hold_base.dataLoop()
discard hold_base.igLoop()
#discard hold_base.audioLoop()
AsyncTaskManager.getGlobalPtr().poll()
when using wasi reactor ( ideal for calling gameloop repeatdly instead of being stuck in main() )
_start vanishes
globals init go into (should be added) to _initializer() actually go in main() but that's just Nim compiler begin funny with reactor model ( should be harmless according to nim lang-dev channel )
wasmtime automatically call _initializer, and then invoke is used to call any exported function
problem:
if not calling main(), gc is probably not active and modules globals are not setup. There is possible undefined behaviour.
but that may not starting GC and complete NiMain routines
=> but bamboo sample works
when calling manually main() to complete _initializer job, with gc inactive
=> bamboo sample works
when calling manually main() to complete _initializer job, with gc( arc/orc ) active.
=> bamboo sample crashes.
normal expected way does not work when GC is active after main was called that line does not pass, usually with cryptic traces : it was hard to locate.
nim-panda3d/direct/showbase/Messenger.nim
Line 15 in ac908ca
neither taskMgr.add later because same model.
removing calls to
.acceptor.addmakes a running sample with a GC and stepping like that