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

More robust chrome process clean-up (take 2) #585

Merged
merged 10 commits into from Sep 6, 2018

Conversation

Projects
None yet
2 participants
@ggeurts
Contributor

ggeurts commented Sep 4, 2018

Compared to #544 the following changes were made:

  • Logging code in ChromiumProcess class ignores exceptions
  • Browser.CloseAsync uses a timeout for graceful close attempts

@ggeurts ggeurts force-pushed the ggeurts:temp-user-data-cleanup branch 2 times, most recently from 0ac87d5 to 2e9cc63 Sep 4, 2018

@ggeurts ggeurts force-pushed the ggeurts:temp-user-data-cleanup branch from 2e9cc63 to b30afbb Sep 4, 2018

@ggeurts ggeurts force-pushed the ggeurts:temp-user-data-cleanup branch from 92360b6 to c93643f Sep 4, 2018

@ggeurts ggeurts force-pushed the ggeurts:temp-user-data-cleanup branch from c93643f to f6376a2 Sep 4, 2018

@ggeurts

This comment has been minimized.

Contributor

ggeurts commented Sep 5, 2018

@kblok I have replaced various Dictionary<K,V> instances in Connection and the CDPSession classes with ConcurrentDictionary<K,V> instances because these dictionaries can be accessed concurrently from different threads. This was especially likely to happen when disposing Browser before all its send operations had completed. In some scenarios this led to race conditions between send, receive and dispose operations.

@kblok

This comment has been minimized.

Owner

kblok commented Sep 5, 2018

@ggeurts Can we revert that and discuss that in another PR?
I tested this PR locally last night and I got no leaks and I wanted to review what was here.
On the other hand, I was thinking over the concurrency deal. I don't want to add a lock on every dictionary call. I'm still which multi-thread scenarios we want to support.

@ggeurts

This comment has been minimized.

Contributor

ggeurts commented Sep 5, 2018

@kblok I can revert, but it will result in a hanging test. The message sending and receiving portions of the code must deal with concurrency because nothing stops a client from initiating multiple sends before awaiting the results, or from disposing a browser when not all messages have been processed yet. I don't see a way here to achieve safe code without using locks. Having said that, I am willing to extract most of the latest changes into a separate pull request.

ggeurts added some commits Sep 5, 2018

@ggeurts

This comment has been minimized.

Contributor

ggeurts commented Sep 5, 2018

@kblok Ok, I have removed the ConcurrentDictionary use, but kept the gist of the other changes to prevent hanging tests. The likelihood of race conditions is less, but certainly still present.

@kblok

Small comments, but this is ready to go!

Show resolved Hide resolved lib/PuppeteerSharp/Browser.cs
Show resolved Hide resolved lib/PuppeteerSharp/Browser.cs Outdated
@kblok

kblok approved these changes Sep 5, 2018

@kblok kblok merged commit 8e6bf11 into kblok:master Sep 6, 2018

2 checks passed

CodeFactor 1 issue fixed.
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment