I am trying to embed a ruby1.9 interpreter in a program. I am currently using forkOS
in my hruby
package, but it seems this only works for ruby 1.8 and 2.x. It looks like 1.9 needs to execute in the primary thread. As a side node, there is no documentation one how to do such a thing, so the only pointer to my current problem is here.
Is there a way to take control of the primary thread to run all my FFI calls ?
Having done some testing and reading of documentation I have come to the following conclusions. The report says all of this is implementation defined so there is no standard way. The module Control.Concurrent
states in its documentation that main is a bound thread however it doesn't require that it is the same as the primary OS thread.
Experimentally (at least on Linux 64-bit with GHC 7.8 and 7.10-rc3) the main thread is the OS thread. Given that the main thread is bound it seems there would be no reason for this to be different on other GHC platforms however I cannot test other platforms.
In terms of actually implementing this if you want to program as if ruby was in a different thread you can run most non-ruby stuff in a different thread and communicate with main thread (which talks to the ruby interpreter) via either MVar
s or TVar
s. See the comment by @chi for an example of how this is done in gtk
.
In terms of a library interface you can have a initialisation function that takes a continuation. Your library hijacks the thread at initialisation and then calls the continuation on another thread. Of course you then need to document to users that it must be called in the main thread.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With