funny.falcon / gmail.com wrote:
> It is impossible to implement Thread migration between native
> threads. All other is possible.

It may be possible but we'd either lose performance and/or break
C extensions.  So it won't happen soon :)

General update on this topic:  I've been piggy-backing
groundwork for this features into trunk as separate issues:

* SIGCHLD-based rb_waitpid into trunk to fix a problem with
  MJIT and it finally appears stable across different platforms:
  https://bugs.ruby-lang.org/issues/14867
  It also helped me understand some portability quirks and
  differences of non-Free platforms I don't use, so I will
  be able to workaround them more easily in the future.

* Since many methods to be affected by green threads need
  timeout args, I'm working on implementing Timeout in the VM:
  https://bugs.ruby-lang.org/issues/14859
  Green-threads versions of rb_wait_for_single_fd, rb_thread_sleep*,
  rb_thread_select, etc... will need to manage their own timeouts,
  anyways.

* Queue+SizedQueue MUST work with this feature, as green thread
  need to communicate with each other.  Same as "mailbox" or
  in actor model or pipes or whatever other languages call it.
  Groundwork for this was already laid in 2.5:
  https://bugs.ruby-lang.org/issues/13552


There will only be one API addition affecting green-thread
creation.  Right now, most likely candidates are:

* Thread::Green.new {} # Just like Thread.new, but with "::Green"

* Thread.green {} # 5 characters shorter than above

* Thread.create(scheduler: ..., args:...) {}  # maybe too verbose

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