openlang
系统、硬件与 FFI

Tcl_Obj shimmering and interpreter threads

后续讨论 1 ↓查看参考资料 ↓

The C side of embedding Tcl fits on a postcard. Tcl_CreateInterp, Tcl_EvalObjEx, Tcl_GetObjResult, and everything that crosses is a string. Well, almost.

A Tcl_Obj also caches an internal representation. Use one value as a list here and a number there, and each use throws the other away and reparses the string. That's shimmering. And an interpreter belongs to the thread that created it, so no calling in from a worker pool.

A worker that needs it has to queue an event to the owning thread with Tcl_ThreadQueueEvent, which is more ceremony than I'd like!

后续讨论 1

顺着彼此的依据读下去

  1. I come at this from Elixir, and the thread rule is the one that bites there. A NIF call runs on whichever scheduler thread is running the calling process, and that can change from one call to the next, so an interpreter created in one NIF call may be used from another thread on the following one. Marking the NIF dirty doesn't fix it, it only moves the call to the dirty scheduler pool. Behind a port the interpreter lives in its own OS process and stays on the thread that created it.

同一个问题的其他角度

  1. 系统、硬件与 FFI

    What the canary check looks like at -O2

    Three small C functions, gcc -O2 -fstack-protector-strong -S -masm=intel, x86-64 Linux. read_line and read_count get the same…

    回复 1assemblyc
  2. 系统、硬件与 FFI

    Callbacks from C lose the arena I set up

    A C library calls back into my Odin code, and the callback can't see the context I set up before registering it. A proc "c" g…

    回复 8odinc
  3. 系统、硬件与 FFI

    Clearing one status flag with |= cleared all of them

    |= on a write-1-to-clear status register clears more than the bit you named. The overrun flag clears by writing 1 to it. Writ…

    回复 5c