-
Notifications
You must be signed in to change notification settings - Fork 0
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
[CLOSED] Clean up Live Development agent loading #3010
Comments
Comment by redmunds In |
Comment by redmunds I don't think we want to take this for Sprint 22. Those are all of the comments I had. |
Comment by jasonsanjose Looks like this will miss the Sprint 23 boat. It's probably too late to take this change. |
Comment by iwehrman I think the requested changes to It shouldn't matter that the addition to Unfortunately, there is yet another problematic race between |
Comment by redmunds I agree that the issue I have with the |
Comment by iwehrman According to the text of I agree that this function sucks, but I don't immediately know how/have time to fix it the right way. I think a new bug is appropriate here. The changes in this patch don't introduce any new problems with this function (as far as I can tell) because some agents are already loading asynchronously. |
Comment by redmunds I opened a new issue for the |
Comment by redmunds
|
Comment by jasonsanjose Thanks for the heads up. I'll let you know soon. |
Comment by jasonsanjose Closing this pull request to manually reconcile with #3442. |
Issue by iwehrman
Thursday Mar 21, 2013 at 18:39 GMT
Originally opened as adobe/brackets#3203
Currently, Live Development agents resolve their
load()
promises before remote services they rely on have been completely enabled. For example,NetworkAgent.load()
callsInspector.Network.enable()
but does not wait for this asynchronous call to complete before returning. This pull request delays completion of these load calls until the necessary asynchronous calls have successfully completed.I'm not aware of any problems caused by the current behavior, but fewer race conditions seems better than more race conditions. Startup races like this also tend to manifest themselves during automated testing.
iwehrman included the following code: https://github.com/adobe/brackets/pull/3203/commits
The text was updated successfully, but these errors were encountered: