[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...

Issue #14723 has been updated by ko1 (Koichi Sasada).

13 messages 2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC — Eric Wong <normalperson@...> 2018/05/01

ko1@atdot.net wrote:

[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...

Issue #14767 has been updated by ko1 (Koichi Sasada).

9 messages 2018/05/17

[ruby-core:87286] [Ruby trunk Feature#14792] Multiple RubyVM in one process to make real multi-threading.

From: sxysxygm@...
Date: 2018-05-29 05:11:45 UTC
List: ruby-core #87286
Issue #14792 has been reported by HfCloud (Xiangyu Shi).

----------------------------------------
Feature #14792: Multiple RubyVM in one process to make real multi-threading.
https://bugs.ruby-lang.org/issues/14792

* Author: HfCloud (Xiangyu Shi)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
  This is an old problem, maybe running multiple RubyVM is a good way, which can really run ruby code in parallel in one process (Each thread runs a RubyVM)and be compatible with old codes(If some codes depend on the GIL, they can still work properly). Some other programming languages have successfully realize it(It is said that lua uses this method, and my friend has make real multi-threading javascript by running multiple ES VM). 

Why do I have this requirement :
  Really parallel threads needed, I choose ruby as the script language in my game engine(https://github.com/sxysxy/HfEngine). And in some situations, I don't need to do too much computation, but I hope they are really running in parallel. (for example,I divide rendering and logic into 2 parts and dispatch them onto two different threads, (putting rendering and logic in one thread is really not a good design)). The logic threads(logic threads are called 'producer', there can be many logic threads) will submit rendering commands list to the rendering thread('consumer'). This process requires to be highly real-time(maybe 3000 times per second), and multi-process will fail to make it.

Possibility:
  1. Some other languages have make it.(As I noticed before)
  2. Though there are many global functions(such as 'rb_define_method'), but GET_THREAD() can help distinguish different threads so different RubyVM. When these functions are called, they can work on specific RubyVM of the calling thread. 
  3. It should be compatible with all existed codes.(I think). including ruby codes and ruby native extensions' codes.(because it do not demand to change any interface)

Hope to add this feature in new ruby.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next