search

wren-lang / wren

The Wren Programming Language. Wren is a small, fast, class-based concurrent scripting language.
http://wren.io
MIT License
6.9k stars 552 forks source link

Considering add thread support? #61

Closed ghost closed 9 years ago

ghost commented 9 years ago

Is it too early to consider something like this? I am interseted to contribute to wren myself and this is the first thing come out off my head. I would love to see that there is a scripting language that does not have a GIL since CPython and Node.js are the ones I use most often but their performance is limited by their GIL somehow.

kmarekspartz commented 9 years ago

On the other hand, this should be done carefully... I think languages with lightweight or green threads implemented in user-space/as part of the runtime have a nicer story for this sort of thing than languages which rely on system or virtual machine threads, e.g. Haskell, Erlang.

See also: https://munificent.github.io/wren/fibers.html

munificent commented 9 years ago

I don't intend to have native OS-level thread support. Wren does have fibers, which let you organize your program in a concurrent way (though you naturally don't get true multicore concurrency from them). For me, that covers much of the benefit of threads.

Hooking up asynchronous IO to fibers is also straightforward. If you're using threads to avoid blocking on IO, fibers can handle this too.

If you do want real concurrency, the Wren interpreter itself has no global state. This means you could write an embedder that keeps multiple Wren VMs running in parallel, with each on its own thread. Of course, you'd be on the hook for doing the thread synchronization when you want to let the VMs communicate with each other.

I'm not philosophically opposed to threads, but they add a ton of complexity to the interpreter, especially the GC. I think fibers cover most (but not all) use cases, with a much simpler implementation and execution model to reason about.

For what it's worth, node doesn't have any sort of locking. It just only ever uses a single thread.

kmarekspartz commented 9 years ago

Instead of the multiple Wren VMs solution, would a native implementation built on top of fibers be possible? I'd imagine a thread could be a fiber which uses blocks to pause and resume computation.

munificent commented 9 years ago

You might be able to get something like that working, but I think you'd find it doesn't buy you anything. Because a single Wren VM only executes a single fiber at a time, as soon as you added enough locking to the threads to make Wren happy, you wouldn't be running any of them concurrently anymore. :(