Skip to content
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

Don't wait on stream listening in DevTools start up #3333

Merged
merged 4 commits into from
Sep 9, 2021
Merged
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 17 additions & 16 deletions packages/devtools_app/lib/src/service_manager.dart
Original file line number Diff line number Diff line change
Expand Up @@ -245,19 +245,6 @@ class ServiceConnectionManager {

service.onEvent(serviceStreamName).listen(handleServiceEvent);

_connectedState.value = const ConnectedState(true);

final isolates = [
...vm.isolates,
if (preferences.vmDeveloperModeEnabled.value) ...vm.systemIsolates,
];

await isolateManager.init(isolates);
if (service != this.service) {
// A different service has been opened.
return;
}

final streamIds = [
EventStreams.kDebug,
EventStreams.kExtension,
Expand All @@ -271,9 +258,9 @@ class ServiceConnectionManager {
serviceStreamName,
];

await Future.wait(streamIds.map((String id) async {
for (final id in streamIds) {
try {
await service.streamListen(id);
unawaited(service.streamListen(id));
} catch (e) {
if (id.endsWith('Logging')) {
// Don't complain about '_Logging' or 'Logging' events (new VMs don't
Expand All @@ -285,7 +272,21 @@ class ServiceConnectionManager {
);
}
}
}));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we are worried about missing isolate events, what if we only await listening to streams that we are concerned about? perhaps kIsolate and kVM?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @jacob314 for input on this

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok thought about this a bit more. If the VM is handling our requests in order we don't need to await any of these as long as we ensure that we send the request over the VM Service for the streams before we preform operations getting the current states of the streams. I would double check that we aren't loading isolate objects before the stream listen code and we should be good.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it matters in this case, but there's no guarantee that the VM service will finish processing a request before a more recent request is completed. Obviously this won't be an issue if you're the only client and you're awaiting on each service request, but just something to keep in mind.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirmed that we are triggering the requests for streams before loading any isolate objects


if (service != this.service) {
// A different service has been opened.
return;
}

_connectedState.value = const ConnectedState(true);

final isolates = [
...vm.isolates,
if (preferences.vmDeveloperModeEnabled.value) ...vm.systemIsolates,
];

await isolateManager.init(isolates);
if (service != this.service) {
// A different service has been opened.
return;
Expand Down