My experience with threading in Pike is that there are at least as many OS level threads as Pike threads, though there may be additional OS level threads created outside of Pike itself (such as libraries and such). Only one thread may be running code that operates on Pike data structures at any given time (coordinated by the Global Interpreter Lock.) Obviously running pike code falls into this category. A thread holding the lock may release it if it does not need to work with Pike data structures for an extended time, such as when running a database query, etc. If an "external" thread needs to run Pike code, it needs to be registered with the runtime (so that the GIL can operate properly).
Bill
On Wed, 29 May 2019, Stephen R. van den Berg wrote:
H. William Welliver III wrote:
On systems that don???t support naming threads, a parameter would be added either to the pike thread object itself or to the underlying OS thread???s thread specific data. In this situation, the thread name would be available through pike, but not in gdb, etc (but it wouldn???t have been anyway, so no big loss there).
Your thread naming solution sounds good.
It is my understanding (even though I have never delved deep into the threading implementation of Pike myself), that most Pike code runs in the equivalent of a single OS thread. Yes, there is some parallelism, but in a very limited way during execution of "native" C-code.
So, it makes me wonder in what way there even is a one-to-one mapping of threads inside Pike and threads at the OS level? -- Stephen.