*world-lock* deadlock issues
Bug #308959 reported by
Nikodemus Siivola
This bug affects 3 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Fix Released
|
Medium
|
Nikodemus Siivola |
Bug Description
Since running almost any user code can cause the *world-lock* to be grabbed (compiler, clos, type-system), it is not safe to run any user code which may communicate with another thread while holding it.
Worst offenders at the moment are compiler output (via Gray streams), and macro and compiler-macro expansion.
Update-
Changed in sbcl: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in sbcl: | |
assignee: | nobody → Nikodemus Siivola (nikodemus) |
Changed in sbcl: | |
status: | Confirmed → In Progress |
Changed in sbcl: | |
status: | In Progress → Triaged |
Changed in sbcl: | |
status: | Triaged → Fix Released |
To post a comment you must log in.
PCL also calls CL:COMPILE for filling its caches, which in turn can block the world.
annoying example:
- asdf is loading something (so, there's a with-compilatio n-unit on the stack)
- a compile error brings up the debugger
- while investigating/ fixing, user tries to use slime fuzzy completion which invokes some generics
- first call, so cache is empty for the generic, thus PCL tries to grab the lock from a random swank worker (to compile a stub?)
- slime hangs