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
How to prevent deadlocks when reload_on_save is enabled #14
Comments
Do you mean saving the document while the package is reloading? |
Yeah, put the focus on the start.py view and start pressing Just for the record, with larger code using a similar pattern than the one exposed in my mcve (ie: global variables using sublime settings function) I won't need to press |
@randy3k Here's the slow manual way I'm testing it right now... if you know a faster way to raise the deadlock I'd be glad to hear it :) |
I thing it is because the execution is too “fast". It takes some time for the reloaded to kick in. I guess the lesson to learn is to wait for the reloaded while reloading in progress. |
With my above snippet is difficult to reproduce, that's why I think not waiting much time between savings is the "best" way to reproduce but with real larger code the deadlock will show up even if i save it in much slower pace (ie: waiting till the progress bar has finished and the message "package whatever reloaded" appears... Tricky stuff :/ ... What do you mean by "it takes some time for the reloaded to kick in" ? Certainly the message "package whatever reloaded" in the status bar doesn't mean the package has kicked in ... So... :) . Asking you this cos if we knew the condition that a module has been "kicked in" not allowing to the users reloading would be cool |
More relevant info, here's a little snapshot once the deadlock happens:
|
if you save the file in a row 10 times without a pause in between, the on_post_save hook won’t be triggered. |
That's interesting... ok, let me ask you something, how would you make the bug show up programatically? Said otherwise, which snippet could emulate the human behaviour of "saving the file in a row N times without a pause in between" to reproduce the bug consistently? Asking you this cos at this point thanks to the snapshots I know basically the piece of code which causes the deadlocks, yeah... global variables trying to access settings files are definitely not cool. But I'd like to know for sure once I've fixed that the deadlock won't appear again. Summing up, at this point I don't understand the real difference between doing Thanks and sorry for posting that many posts but this problem has been bothering me already for a while... although it's quite interesting one as I've learned quite a lot of cool stuff in the road :) |
I didn’t test this, but try
|
Thx, let me try, right now I was playing with the below one and I was getting +/- consistent crashes after spawning it 1 or 2 times:
|
If you run the command |
You're absolutely right... btw, I'd also tried with set_timeout_async and it wasn't making any difference, just for the record, the below with the hardcoded values seems to crash ST quite consistently \o/ (although sometimes you need to spawn it couple of times):
|
I guess a fix would be setting a global flag which indicates loading is in progress. Any subsequential save command won’t trigger the reloader if the flag is set. |
That'd be indeed a great fix, but I guess the question here is... is there any way to know whether the loading has been completed (including async code) or not? Maybe this one https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap.py#L194 could help? dunno... :/ |
We can tell when the plugin has finish reloading https://github.com/randy3k/AutomaticPackageReloader/blob/master/package_reloader.py#L99. It would be the developer responsibility to handle the loading of asynchronous code. |
Fair enough, sounds like an easy and decent solution to me. I think that'd be a good default behaviour of the plugin... On the other hand, being able to stress test and reloading a package could be also quite interesting to check packages are robust enough and find possible issues. So I guess a settings bool variable such as Btw, I see a lot of hardcoded numbers in this piece of code, guess coming up with a more robust solution wouldn't be straightforward? Regards |
@randy3k Randy, hi there, nice to meet you. Yesterday I was facing a nasty bug while reloading some code of mine using your package and after a lot of researching I've discovered in some edge-case a deadlock will be created. I've come up with a little reproducer and added some details here.
Right now I'd like to come up with some way to reproduce the deadlock much faster... I was thinking maybe spawning "Package reloading" in a loop intensively would do, I'll test it out later.
Anyway, in case you're also interested, please let me know your thoughts, advices, ...
Thx in advance!
The text was updated successfully, but these errors were encountered: