Well since Ruby's native threading isn't perfect. I got to thinking, if something like Distributed Ruby can share objects over the network, why wouldn't I be able to do something over several processes?
It's way in the future for me to get time to do something major like this. Who knows maybe someone beats me to it. But was interested in hearing peoples thoughts on this. Also Laurent if you like the idea and if I should include it directly into the bindings to compensate real native threading, or if I should keep it separated from the bindings.
For you Laurent that isn't familiar with Ruby. Previously ruby(1.8.x) had green threads so they were managed internally by the VM. But in the latest ruby(1.9.x) they have switched to native threads, BUT there's a GIL(Global interpreter lock) in place which enforces only 1 thread to be running ruby code(though any extensions to ruby using threads can still run). So more or less, if you create a thread in Ruby you do get parallelism, but not the benefits of it. That's what I want to try and achieve.
Anyway my idea is something like:
thread = SFML::Thread.new do |thread|
# This is run in another process, so it isn't really a thread.
thread[:var] = 5
thread[:obj] = Object.new
while thread.continue?
thread[:var] += 1
thread.yield # When yielding, the process will look if it got any pending messages.
end
end
puts thread[:var] # Send a message to the thread that we would like to look at :var
puts thread[:obj].to_s # Any method calls to objects also will go trough inter-process messaging.
object = thread[:obj] # Actually only returning a virtual object wrapping any calls on to the process.
The only problem with this that I can't get around is that there will be A LOT of blocking between the processes. Every time we want data from the "thread" the parent will have to wait for the child to yield and any pending messages processed. Then again, if you need to exchange a lot of data between threads, then things aren't really paralleling.
Also worth noting, this is already more or less supported. You can use distributed ruby, but then all "messaging" will go trough the network in order to reach your process.