Crystal: Will it be possible to opt out of multithreading?

[r00ster91]

There still seem to be some issues with multithreading because some parts of the standard library aren't thread-safe, so fixes are being discussed, with some of them possibly making the performance a bit worse (like the usage of mutexes), so that multithreading properly works and there are no thread safety issues.
Now I'm wondering, what's with programs that don't need multithreading?
Like programs that don't utilize parallelization, or just very barely so that they could also run on a single core, short-living programs etc. Will there, even when multithreading is fully finished be a flag to opt out of the whole multithreading thing? I hope so because putting down the performance of all programs because of multithreading wouldn't be so good.
I'm fine with it becoming the default, I'm just asking to keep the whole multithreading stuff behind like an {% if !flag?(:no_mt) %} or an {% unless flag?(:no_mt) %}.

[Blacksmoke16]

Wouldn't you just do like CRYSTAL_WORKERS=1?

[r00ster91]

Hmm no, I don't think that solves it. I mean yeah that will make it use only one core, but then the multithreading stuff is still used. For one core the current implementation should be used. And that's why I'm talking about using macro flags. Like here:
https://github.com/crystal-lang/crystal/blob/a59f1a7fd4e32c0b53762632ea7ed48c12b3c258/src/crystal/scheduler.cr#L20
{% if flag?(:preview_mt) %} should eventually become {% if !flag?(:no_mt) %}.

[girng]

I spin up my game instance servers on single core/threaded VPSs, so I vote yes.

[bcardiff]

So far the idea is to keep a single thread mode. So, yes.

Whether the multi-thread or single-thread will be the default it is not settle yet.

[asterite]

This is just my opinion and it won't affect the decision, but I think keeping single threaded mode is a very bad idea. It means people might write shards and use them in single-threaded mode (don't care about data sharing, for example) but then others might use them in multi-threaded mode and encounter crashes or unexpected behavior. Then depending on a shard becomes unreliable because you never know if it will work properly under multithreading.

If multithreading is the only option then your only chance is to make your shard work with that in mind, making bad behavior less possible.

Go has no option for single thread, and Go is incredibly popular and there are hundreds of excellent tools written in it. I don't think people complain about Go not running in single thread.

If performance is a worry then it's just a matter of time before things are optimized. Just look at @firejox 's PRs, MT is still behind a flag and they are already improving the performance.