Open mahills opened 10 years ago
One idea may be to just not automatically re-import resource modules, that would at least prevent this problem. Can anyone see any problems with that?
Hmmm.. Otherwise it could be fixed by cloning the todo list quickly under lock, and then reloading, then generated modules would become dirty and get loaded again... I believe you are right and we can forget about automatic reload of generated modules, as long as they are always loaded from scratch right after regeneration. — Jurgen J. Vinju CWI SWAT INRIA Lille UvA master software engineering http://jurgen.vinju.org
On Thu, Jun 12, 2014 at 8:03 PM, mahills notifications@github.com wrote:
One idea may be to just not automatically re-import resource modules, that would at least prevent this problem. Can anyone see any problems with that?
Reply to this email directly or view it on GitHub: https://github.com/cwi-swat/rascal/issues/589#issuecomment-45926572
Here is the stack trace from
jstack
showing where the deadlock is occurring. My guess -- without having looked into this extensively yet -- is that the following is occurring:run
method inRascalScriptInterpreter
calls theModuleReloader
to update the modules before actually evaluating the command. This is inWorker-195
.ModuleReloader
locks the set ofdirtyModules
and then goes through to reload what has changed. One of the changes is with a generated resource module; reimporting this (withinWorker-195
) regenerates the module file.Worker-189
) is a resource change, which triggers a call to the listener to say that a loaded module, the one we just generated, has changed. This call tomoduleChanged
inRascalModuleChangeListener
wants to lockdirtyModules
, but cannot.I'll take a look at this, but if anyone else wants to jump in be my guest :)