Allow the thread-impl to be switched by configure option

[kateinoigakukun]

This is a preparation for porting MRI to WebAssembly. In WebAssembly, there is no thread feature, so we need to add "no thread mode" in MRI.
That mode is not limited to the WebAssembly target, and other platforms will be able to use it also. This means a platform will have multiple candidates for thread implementation.

This patch allows the thread impl to be switched by configure option instead of selecting an implementation based on target platform. e.g. --with-thread=[pthread|win32]

[nobu]

Needs to add THREAD_IMPL_H and THREAD_IMPL_SRC to $(CONFIG_H) in win32/Makefile.sub.

[kateinoigakukun]

@nobu Thank you for your quick review and advice! I was just investigating the ci failure on the Windows environment 😅

[kateinoigakukun]

@ko1 suggested THREAD_MODEL should be renamed to THREAD_IMPL in slack because it's conflicted with a word that represents a model like M:N multithreading.

But THREAD_MODEL is already used in many places, so I want to rename them in another PR. What do you think, @ko1 and @nobu?

[kateinoigakukun]

I think this is ready to merge. Is there any other change request?

[ioquatix]

I think this is a great idea and I'd like to see this expanded to CRuby in general - i.e. a Ruby build without threads. However, we might like to still support threading primitives. Can we also support Fibers in WebAssembly?

[kateinoigakukun]

@ioquatix In my understanding, we can't port the current Fiber implementation to WebAssembly due to lack of context switching mechanism. Wasm can switch its execution context to only "back" in a call stack (e.g. like exception unwinding), and it can't jump "across" call stacks.

[ioquatix]

Do you have access to threads? You can implement crappy fibers using threads with a execution exchange mechanism. There is a pthread implementation of Fibers in CRuby now.

[ioquatix]

How does this relate to web assembly? https://emscripten.org/docs/api_reference/fiber.h.html

[hsbt]

@kateinoigakukun Basically, We need to discuss the new feature on https://bugs.ruby-lang.org/ . I'm not sure this proposal is a trivial changes or bugfix.

[kateinoigakukun]

Let me clarify that this patch does not add any new thread implementation in the language but just adds a way to switch implementations in configure. The none thread implementation will come with subsequent patches. I maybe need to create a new ticket for it.

Do you have access to threads? You can implement crappy fibers using threads with a execution exchange mechanism. There is a pthread implementation of Fibers in CRuby now.
How does this relate to web assembly? https://emscripten.org/docs/api_reference/fiber.h.html

Good point. Unfortunately, WebAssembly doesn't have a way to create or join threads by itself yet. The responsibility of creating and joining threads is deferred to the embedder of WebAssembly runtime. https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md

Emscipten depends on JavaScript embedders mechanism to provide such extra features like threads or socket, so it cannot be run with non-JavaScript environments like wasmtime or wasmer.
My project aims to provide JavaScript independent WebAssembly binary of MRI, so can't use the emscripten's API for this purpose.

[mame]

I think that this change is almost for refactoring, and trivial.

As for WebAssembly, not only the implementation approach but also the feasibility are not yet clear. Let's discuss it in https://bugs.ruby-lang.org after a proof-of-concept is created.