Question: How to use this in multi-threaded environment?

[Robbepop]

First of all: Nice crate and API!

I am trying to use your region crate in order to efficiently model virtual memory for my virtual machine: https://github.com/Robbepop/runwell

The crate's docs are telling about issues with multiple threads but gave no suggestion in how to operate in that environment properly: https://docs.rs/region/3.0.0/region/#parallelism

For my project I have this thin-wrapper for region::Allocation: https://github.com/Robbepop/runwell/blob/master/crates/vmem/src/lib.rs ... and some unit tests on top: https://github.com/Robbepop/runwell/blob/master/crates/vmem/src/tests.rs

Using cargo test --package runwell_vmem results in 3 different scenarios:

• It works! (80%)
• Bug 1: Invalid Memory Reference (~15%)

  process didn't exit successfully: `/home/user/projects/runwell/target/debug/deps/runwell_vmem-de3149ae5e1f53dc` (signal: 11, SIGSEGV: invalid memory reference)

• Bug 2: Cannot Allocate Memory (~5%)

  thread '<unnamed>' panicked at 'failed to set up alternative stack guard page: Cannot allocate memory (os error 12)', library/std/src/sys/unix/stack_overflow.rs:160:13
  
  0: rust_begin_unwind
           at /rustc/bd41e09da334697c0f993b36685cb599061d9faa/library/std/src/panicking.rs:517:5
  1: std::panicking::begin_panic_fmt
           at /rustc/bd41e09da334697c0f993b36685cb599061d9faa/library/std/src/panicking.rs:460:5
  2: std::sys::unix::stack_overflow::imp::get_stackp
           at /rustc/bd41e09da334697c0f993b36685cb599061d9faa/library/std/src/sys/unix/stack_overflow.rs:160:13
  3: std::sys::unix::stack_overflow::imp::get_stack
           at /rustc/bd41e09da334697c0f993b36685cb599061d9faa/library/std/src/sys/unix/stack_overflow.rs:166:32
  4: std::sys::unix::stack_overflow::imp::make_handler
           at /rustc/bd41e09da334697c0f993b36685cb599061d9faa/library/std/src/sys/unix/stack_overflow.rs:177:21
  5: std::sys::unix::stack_overflow::Handler::new
           at /rustc/bd41e09da334697c0f993b36685cb599061d9faa/library/std/src/sys/unix/stack_overflow.rs:14:9
  6: std::sys::unix::thread::Thread::new::thread_start
           at /rustc/bd41e09da334697c0f993b36685cb599061d9faa/library/std/src/sys/unix/thread.rs:104:32
  7: start_thread
  8: __GI___clone
  
  process didn't exit successfully: `/home/user/projects/runwell/target/debug/deps/runwell_vmem-de3149ae5e1f53dc` (signal: 6, SIGABRT: process abort signal)

Using cargo test --package runwell_vmem -- --test-threads 1 solves the problem. So it is pretty clear that the concurrently running test threads are kinda having conflicts with each other.

From the Rust point of view those tests do not have shared data and yet they compromise each other. I am sure I have some misconception or misunderstanding about the underlying APIs.

I was trying to remove as many of the unit tests to see which minimum subset still triggers the above bugs: At minimum the grow_to_capacity_works, grow_works, read_write_works unit tests need to be run.

Please help to resolve my misconceptions about this crate and its invariants and ideally help me on track so that I can actually use this nice API of yours. :)

[Robbepop]

Closed as my misunderstanding was with the alloc_at function since I thought it allows for resizing the virtually allocated memory which it does not. For this we'd need support for mremap on unix, however, to my knowledge there is no dedicated Windows API for resizing virtual memories which is probably why this crate does not support it.