Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • M mu-impl-fast
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 40
    • Issues 40
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • mumu
  • mu-impl-fast
  • Issues
  • #55
Closed
Open
Issue created Jul 07, 2017 by Isaac Gariano@igariano01Maintainer

Cannot drop a lock in `throw_exception_internal`

In my latest commit, I have modified the structure of the exception table (so that it dosn't use unsafe pointers, and in order to fix Issue #53 (closed) ). In throw_exception_internal I acquire a read lock the compiled_callsite_table, we wan't this lock to be realesed before calling exception_restore, however the borrow checker won't let me:

error[E0505]: cannot move out of `compiled_callsite_table` because it is borrowed
  --> src/runtime/exception.rs:89:18
   |
65 |             let table_entry = compiled_callsite_table.get(&callsite);
   |                               ----------------------- borrow of `compiled_callsite_table` occurs here
...
89 |             drop(compiled_callsite_table); // drop the lock first
   |                  ^^^^^^^^^^^^^^^^^^^^^^^ move out of `compiled_callsite_table` occurs here

So I have commented out line 89, and things seam to work. The function exception_restore is marked as non-returning, so perhaps the rust compiler is smart enough to do the drop for us, if it isn't, we will get a deadlock if someone tries to acquire a write lock once an exception has been thrown (however currently we only modify the table once at startup, before any exceptions are thrown, so this won't occur).

Assignee
Assign to
Time tracking