Just a word of encouragement here. The ways in which ruby seems to differ between installed and in-tree testing has bitten me doing Ruby+OMR work a number of times, and I'd love to see some simplification. (In particular, I load Ruby...magaudet (Matthew Gaudet)
So, I'd love to use a native thread to do compilation, however, that means compilation is cut off entirely from the interpreter: Any and all `rb_` family functions that are only callable under the GVL become out of bounds. In the short t...magaudet (Matthew Gaudet)
In this feature I propose creating a VM implementation feature called (for lack of a better name) *System Threads*. Background ========== I am working on adding asynchronous compilation to [Ruby+OMR][1] allow compilation of meth...magaudet (Matthew Gaudet)
Thinking more on this, I'm wondering if maybe I would still like to be in a situation where the compilation thread is a ruby thread (and in fact, today, have a working version that runs this way -- I got rid of `rb_thread_wait_for`--, bu...magaudet (Matthew Gaudet)
I'm currently working on adding asynchronous compilation to [Ruby+OMR][1], and I'm trying to use the existing Ruby thread API. However, given that compilation shouldn't happen while holding the GVL, I've been playing with `rb_thread_call...magaudet (Matthew Gaudet)
vmakarov (Vladimir Makarov) wrote: > Sorry, Matthew. I can not find your message on > ... Very curious! I don't quite know what went wrong... so here I am writing a reply in Redmine to make sure it shows up for future searchers :) ...magaudet (Matthew Gaudet)