Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Borrowing panics inside EventStream implementation #137

Closed
netvl opened this issue Oct 25, 2018 · 2 comments
Closed

Borrowing panics inside EventStream implementation #137

netvl opened this issue Oct 25, 2018 · 2 comments

Comments

@netvl
Copy link

@netvl netvl commented Oct 25, 2018

I've got several panics coming from borrow() invocations inside the EventStream implementation, for example:

hread '<unnamed>' panicked at 'already borrowed: BorrowMutError', libcore/result.rs:1009:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:476
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: rust_begin_unwind
             at libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::result::unwrap_failed
             at libcore/macros.rs:26
   9: <core::result::Result<T, E>>::expect
             at libcore/result.rs:835
  10: <core::cell::RefCell<T>>::borrow_mut
             at libcore/cell.rs:885
  11: <relm_core::EventStream<MSG>>::emit
             at /home/netvl/.cargo/registry/src/github.com-1ecc6299db9ec823/relm-core-0.15.0/src/lib.rs:222
  12: <file_projections::ui::Emitter as core::ops::function::Fn<(file_projections::ui::Msg,)>>::call
             at src/ui.rs:123
  13: file_projections::ui::MainWindow::callback::{{closure}}
             at src/ui.rs:139
  14: file_projections::db::Db::get_source_path::{{closure}}
             at src/db.rs:86
  15: <F as threadpool::FnBox>::call_box
             at /home/netvl/.cargo/registry/src/github.com-1ecc6299db9ec823/threadpool-1.7.1/src/lib.rs:95
  16: threadpool::spawn_in_pool::{{closure}}
             at /home/netvl/.cargo/registry/src/github.com-1ecc6299db9ec823/threadpool-1.7.1/src/lib.rs:767

I actually clone the EventStream coming from the Relm instance, and use it to send messages back to the UI from a separate thread.

If EventStream is not supposed to be used in this fashion, then I think it should not be Send/Sync, so issues like this could be prevented by the compiler.

@antoyo
Copy link
Owner

@antoyo antoyo commented Oct 26, 2018

Yeah, they should not be Send/Sync.
Please use Channel instead.

I'll fix this issue.
Thanks for reporting it.

@antoyo
Copy link
Owner

@antoyo antoyo commented Nov 16, 2018

Fixed in #148.

@antoyo antoyo closed this Nov 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants