You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On src/racer/ast.rs, there are multiple methods whose implementation looks something like this:
let thread = Thread::scoped(move || {let stmt = string_to_stmt(s);letmut v = ImplVisitor{name_path:None,trait_path:None};
visit::walk_stmt(&mut v,&*stmt);return v;});return thread.join().ok().unwrap();
Since this is using Thread::scoped (which makes the parent thread wait on the thread.join() call), there isn't any gain in performance here - on the contrary, there's a big performance loss. On my linux system, a call to racer complete std::old_io:: spawns 108 threads, and spends almost half of its execution time on the futex syscall (thread synchronization).
On a comment, there's a possible justification for this - handling panic!s from the parser, since Rust provides no way to "catch" panic!s. The problem with this justification is twofold - first, methods as the one above (which are by far the most common on the file I mentioned) aren't actually catching anything, since they unwrap() the final result of thread.join() - meaning that a panic! will be propagated to the parent thread anyway. Secondly, per rust-lang/rust#22435, "catching" panics at the border of a scoped thread won't be supported by the stdlib anymore - which means that racer won't be able to use this technique anymore in a few days.
I'm opening this issue so that we can discuss a possible solution for this - hopefully one that doesn't use threads for control flow :)
The text was updated successfully, but these errors were encountered:
Hi Renato,
You are correct in thinking it was originally to catch panics. Racer has got much better at passing parsable blobs of code to libsyntax now so it's not needed and remains mainly because of my lazy copy-paste coding style! Feel free to fix if you want, or I'll repair it when rust-lang/rust#22435 hits.
BTW Thanks for pointing me at rust-lang/rust#22435 - I'll check out the discussion.
On
src/racer/ast.rs
, there are multiple methods whose implementation looks something like this:Since this is using
Thread::scoped
(which makes the parent thread wait on thethread.join()
call), there isn't any gain in performance here - on the contrary, there's a big performance loss. On my linux system, a call toracer complete std::old_io::
spawns 108 threads, and spends almost half of its execution time on thefutex
syscall (thread synchronization).On a comment, there's a possible justification for this - handling
panic!
s from the parser, since Rust provides no way to "catch"panic!
s. The problem with this justification is twofold - first, methods as the one above (which are by far the most common on the file I mentioned) aren't actually catching anything, since theyunwrap()
the final result ofthread.join()
- meaning that apanic!
will be propagated to the parent thread anyway. Secondly, per rust-lang/rust#22435, "catching" panics at the border of ascoped
thread won't be supported by the stdlib anymore - which means that racer won't be able to use this technique anymore in a few days.I'm opening this issue so that we can discuss a possible solution for this - hopefully one that doesn't use threads for control flow :)
The text was updated successfully, but these errors were encountered: