Export RbConfig::CONFIG["COROUTINE_TYPE"]

THREAD_MODEL is exported already, so this matches that. Exporting this is simpler than inspecting configure_args and arch and matching that up with a specific configure.ac.

I was trying to debug a segfault is only reproducible with specific coroutine types and compiler flags, and wanted this in order to simplify my testing script.

I changed the case to uppercase, but if it should remain lower-case (or use a different name), I can resubmit with that.

I'm unsure if COROUTINE_TYPE is an appropriate name. I think the "COROUTINE" is kinda code name in Ruby implementation. If we provide it as a public interface, I propose another name RbConfig::CONFIG["CONTEXT_SWITCHER_TYPE"].

cc/ @ioquatix

Coroutine has standard meaning and I think the export is okay but I'm happy to discuss alternatives. I don't think CONTEXT_SWITCHER_TYPE is better, it seems less obvious what it is to me.

I think https://en.wikipedia.org/wiki/Coroutine is a generic name for a language feature that can be used as various control flows. On the other hand, Ruby's coroutine is just a wrapper for makecontext/swapcontext or its comaptible platform-dependant implementations for Fiber. In light of the reality of Ruby's coroutine, FIBER_IMPLEMENTATION_TYPE might be appropriate.

Coroutine exists independently of Fiber, so I'm not sure tying it to Fiber makes sense. A fiber is just another name for a stackful coroutine. There is also stackless coroutine.

I think the original terminology is correct and there is no value in making it more complex.

Every other implementation I've looked at uses the same terminology (coroutine) to describe the functionality of transferring between two stacks and instruction pointers. See for example:

• https://github.com/Tencent/libco
• http://software.schmorp.de/pkg/libcoro.html

Is there some reason why you are against COROUTINE_TYPE?

If anything, I'd say "_TYPE" is the most confusing word, and if anything, maybe we should rename it "COROUTINE_IMPLEMENTATION" both internally and externally. But I'm not sure there is any big advantage.

I'm okay with any of /^(FIBER|COROUTINE|(CONTEXT|STACK)_SWITCH(ER)?)_(TYPE|IMPL(EMENTATION)?|MODE)$/. 😉

"coroutine" encompasses: Thread-bound stackful fibers (like we already have), Thread-jumping stackful coroutines (more like goroutines; maybe a new class or maybe just Fiber with a flag), continuation-passing-style async/await methods (IDK, maybe as a performance optimization?), or even just PORO state machines (if it quacks like a coroutine).

But I suppose my preference is based on whether we expect implementation details to vary based on type:

• Would amd64, arm64, wasm, etc Fiber implementations be strongly correlated with amd64, arm64, wasm, etc implementations for Thread-jumping stackful coroutines?
  • No: are you sure? I think they would! 😝 But if not: FIBER_IMPL
• Would stackless-coroutines share nearly the same implementation on every platform?
  • Yes: COROUTINE_IMPL - covers everything that varies <<< This is my assumption.
• Would amd64, arm64, wasm, etc Fiber implementations be strongly correlated with amd64, arm64, wasm, etc implementations for stackless coroutines (e.g. CPS async/await)?
  • Yes: COROUTINE_IMPL - covers everything that varies
  • No: CONTEXT_SWITCH_IMPL (and use e.g. CONTINUATION_PASSING_IMPL for CPS stackless)

So I guess I have a weak preference for COROUTINE_IMPL. But any of them seems reasonable to me. 🙂

Is there some reason why you are against COROUTINE_TYPE?

I think "coroutine" is a name of a language feature, not a name of any implementation. Ruby provides no feature named "coroutine". This is just a reason.

libco and libcoro are libraries to mimic coroutine in C language. On the other hand, Ruby's coroutine/ is just a part of implementation of Ruby to implement a Fiber, in my perspective. I wonder if there is any reason to dare to export the name "coroutine" in Ruby.

However, I have noticed that ./configure already exposed --with-coroutine=IMPLEMENTATION, so my concern might be too late. I'm okay with COROUTINE_IMPL or COROUTINE_IMPLEMENTATION.

I think "coroutine" is a name of a language feature, not a name of any implementation.

Isn't it also true for "thread" in an abstract sense?

I think "coroutine" is a name of a language feature, not a name of any implementation.

Isn't it also true for "thread" in an abstract sense?

I am not sure what your question is about. Do you mean RbConfig::CONFIG["THREAD_MODEL"]? Since the Ruby language provides a feature officially named "Thread", I don't see any problem to use the name in RbConfig.

I understand your position. I was actually interested in the distinction between coroutine a language feature and coroutine an implementation and found this nice document: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4024.pdf I think it does a good job of explaining the differences and characterising the "Fiber" as a language feature vs "Coroutine" as an implementation detail.

With all this discussion, I'm not sure there is much value in changing from COROUTINE_TYPE. I think it's understandable enough and as you said, it's already configure flag. Unless there is strong reason to change it and someone cares enough to make a PR, I'd probably just say, let's leave it as is. I'd be fine with COROUTINE_IMPLEMENTATION but then let's update it to be consistent, e.g. --with-coroutine-implementation=... and so on.