title: Shipping stack data in and out of closures
body: <p>I have a C function that for various C reasons can only be called from certain kinds of threads.  I'm trying to call this function from Rust.</p>
  
  <p>The idea that I had was to ship the input data onto the "right" thread, call the C function on that thread, and then wait on the thread using a semaphore before shipping its return value back out.</p>
  
  <p>The thread isn't used for concurrency; it's really a rather synchronous execution flow.  It's simply that the C function is persnickety about how it can be used.</p>
  
  <p>This was my attempt:</p>
  
  <pre><code>use std::thread::Thread;
  
  struct Foo {
      x: std::sync::Semaphore,
  }
  
  //Not the real C function, of course.
  fn my_great_c_function(i: i32) -&gt; i32 {
      println!("{}",i);
      return 12;
  }
  
  impl Foo {
      fn bar(&amp;self) {
          self.x = std::sync::Semaphore::new(0);
          let input : i32 = 5;
          let mut output : i32 = 10;
          Thread::spawn(|:| {
              //call out to our C function that only likes some threads
              output = my_great_c_function(input);
              self.x.release(); //our work is done; the parent thread can continue
          });
          self.x.acquire(); //wait for child thread to be done interacting with environment
          println!("{}",input); //check input
          println!("{}",output); //check output
      }
  
  }
  </code></pre>
  
  <p>The Rust compiler outputs a whole page of errors explaining that it <code>cannot infer an appropriate lifetime due to conflicting requirements</code>.  </p>
  
  <p>From what I can piece together I think the compiler is concerned that the closure may outlive the stack frame, and the closure's references to <code>input</code> and <code>output</code> may get blown away while the closure is still using them (this is, I suspect, the meaning of <code>lifetime parameter must outlive the static lifetime</code>).  But in fact, the semaphore is used to keep the stack frame alive until the closure finishes, so that shouldn't happen.</p>
  
  <p>Is there some way to calm the compiler?  Is there a different way to solve this problem?</p>