-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Behavior of Thread::new() on passed instances #39
Comments
Hello @mattn any update on this? |
Sorry, I'll look into it in later. |
@mattn no problem, didn't want to put pressure, just wanted to be suer you got the notification. More than often it happened to me 😉 |
Yes, please do it. I hope that mruby-thread can handle instances created by another thread. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The original implementation (see also #38) is designed so that
Thread.new(a)
makes a full copy ofa
in the newly created thread (unlessmrb_type(a) == MRB_TT_DATA
).As a consequence, changes to
a
in any given thread are not visible to the other threads. This way, passing information between threads becomes a hard task.Since I am still not sure about the reasons behind this choice, I have made an experimental branch in my own fork (pbosetti/mruby-thread) where the C macro
MRB_THREAD_COPY_VALUES
can be set to enable the original behavior (make copies) or leave undefined to switch to a "share the same instances" behavior.The script
examples/data.rb
can be used to compare the two cases: whenMRB_THREAD_COPY_VALUES
is set, the changes to globals$data
and$ary
made in the subthread are not visible into the main thread. Conversely, ifMRB_THREAD_COPY_VALUES
, any change to instances passed toThread::new()
are visible to other threads.The question is: can I make a PR for this?
Thanks,
Paolo
The text was updated successfully, but these errors were encountered: