How to write tests with VM::init? #118
Comments
|
There can be only one If your code comments run test code then simply put a hashtag before VM::init() to have them not conflict |
Per thread? I still don't understand why your testsuite in |
|
There are some key differences between your code and the code here: You're using |
|
I tried your solution before. The same. |
|
Ok. Issue is with using Here is STR. Create brand new projectCargo.toml[dependencies]
rutie = "0.7.0"
lazy_static = "1.4.0"src/lib.rsextern crate rutie;
#[macro_use]
extern crate lazy_static;
use rutie::{VM, Object, Fixnum, Array};
use std::sync::{RwLock};
#[cfg(test)]
lazy_static! {
pub static ref LOCK_FOR_TEST: RwLock<i32> = RwLock::new(0);
}
#[test]
fn test_two_plus_two() {
# We don't need lock here.
assert_eq!(2 + 2, 4);
}
#[test]
fn test_array_length() {
let _guard = LOCK_FOR_TEST.write().unwrap();
VM::init();
let array = Array::new();
assert_eq!(array.length(), 0);
}
#[test]
fn test_array_protect_send() {
let _guard = LOCK_FOR_TEST.write().unwrap();
VM::init();
let mut array = Array::new();
array.push(Fixnum::new(101).to_any_object());
let first = array.protect_send("first", &[]).unwrap();
assert_eq!(first, Fixnum::new(101).to_any_object());
}Run in sequenceIt never fails. Run in parallelRun several times and sometimes it fails. Looks like it depends on order which thread obtains lock first ( With RUST_BACKTRACE=1Why |
|
BTW What is philosophy of using unwrap with protect methods.
|
|
I did few experiments with dumb program writing: #[macro_use]
extern crate rutie;
#[macro_use]
extern crate lazy_static;
use rutie::{VM, Object, Fixnum, Array};
use std::sync::{RwLock};
lazy_static! {
pub static ref LOCK_FOR_TEST: RwLock<i32> = RwLock::new(0);
}
fn test_array_length() {
let _guard = LOCK_FOR_TEST.write().unwrap();
eprintln!("test_array_length: START");
let array = Array::new();
let length = array.length();
println!("length: {}", length);
}
fn test_array_size() {
let _guard = LOCK_FOR_TEST.write().unwrap();
eprintln!("test_array_size: START");
let array = Array::new();
let size = array.protect_send("size", &[]).unwrap().try_convert_to::<Fixnum>().unwrap().to_i32();
println!("size: {}", size);
}
fn main() {
main_work();
//main_does_not_work_1();
//main_does_not_work_2();
//main_does_not_work_3();
}
fn main_work() {
let child2 = std::thread::spawn(move || {
VM::init();
test_array_size();
});
let res2 = child2.join();
}
fn main_does_not_work_1() {
VM::init();
let child2 = std::thread::spawn(move || {
test_array_size();
});
let res2 = child2.join();
}
fn main_does_not_work_2() {
let child1 = std::thread::spawn(move || {
VM::init();
test_array_length();
});
let child2 = std::thread::spawn(move || {
VM::init();
test_array_size();
});
let res1 = child1.join();
let res2 = child2.join();
}
fn main_does_not_work_3() {
VM::init();
let child1 = std::thread::spawn(move || {
test_array_length();
});
let child2 = std::thread::spawn(move || {
test_array_size();
});
let res1 = child1.join();
let res2 = child2.join();
}So it looks like we cannot work with Ruby VM in from different RUST threads at all. @danielpclark Is it true? |
|
On these questions:
Finding a way to write code without using unwrap leads to better safer code. Sometimes and some places need unwrap, but often there are better ways to do a thing.
I'm not quite sure I get the question.
Mapping is the most concise way to do it. If the main application is a Ruby app then the answer is yes.
I don't know. What I do know is Ruby has it's own global thread state per Ruby thread which will within it's own thread throw exceptions that break the current Ruby thread's process for any error handling to proceed. If multiple Rust threads are running off of one instance of Ruby then one should consider how to properly handle a failing rust thread in such a way that the Ruby process will respond accordingly.
I would expect we could… but I might recommend 1 master Rust thread in which it handles all communication between Rust and Ruby and that 1 master Rust thread can have many other threads acting like sub-processes. |
Hi there!
I have very trivial lib:
lib.rs
service.rs
Some module with dumb trival assertions:
Run tests
If tried different locks implementations, serial_test cargo, etc. Nothing works. Same crash (time to time)
The only one workaround that it REALLY works is to run all specs in SEQUENCE:
I wonder how internal rutie tests still works with their LOCK_FOR_TEST locker.
https://github.com/danielpclark/rutie/blob/master/src/class/integer.rs#L207
Did I do something wrong?
Thx in advance.
The text was updated successfully, but these errors were encountered: