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

Tests and code for various SPDY close scenarios. #46

Merged
merged 1 commit into from
Oct 7, 2012

Conversation

swankjesse
Copy link
Collaborator

Writing this change has led me to believe that the
concurrency here is just plain awful, and I need to
find a better solution than what I have. In particular,
there are too many threads:

  • the internal reader thread
  • application reader threads
  • application writer threads
    And too many locks:
  • the SpdyWriter I/O write lock
  • the SpdyConnection internal state lock
  • each SpdyStream's internal state lock

What's currently very wrong is the internal reader thread
is updating state in the SpdyStream, and reading bytes from
the network into a particular stream. It is an error to hold
the SpdyStream's lock while reading, but we're doing it because
we need to hold the state on the buffer, position and limit.
We need to rethink this!

Chrome doesn't run into this problem because it can 'fire and
forget' events. We can't do that because SPDY writes need to
throw IOExceptions if the writes fail.

Writing this change has led me to believe that the
concurrency here is just plain awful, and I need to
find a better solution than what I have. In particular,
there are too many threads:
 - the internal reader thread
 - application reader threads
 - application writer threads
And too many locks:
 - the SpdyWriter I/O write lock
 - the SpdyConnection internal state lock
 - each SpdyStream's internal state lock

What's currently very wrong is the internal reader thread
is updating state in the SpdyStream, and reading bytes from
the network into a particular stream. It is an error to hold
the SpdyStream's lock while reading, but we're doing it because
we need to hold the state on the buffer, position and limit.
We need to rethink this!

Chrome doesn't run into this problem because it can 'fire and
forget' events. We can't do that because SPDY writes need to
throw IOExceptions if the writes fail.
JakeWharton added a commit that referenced this pull request Oct 7, 2012
Tests and code for various SPDY close scenarios.
@JakeWharton JakeWharton merged commit b6e785e into master Oct 7, 2012
swankjesse pushed a commit that referenced this pull request Apr 23, 2023
As described in UTS #46, https://www.unicode.org/reports/tr46

This is working towards OkHttp's own implementation of what
IDN.toASCII() does on the JVM.
swankjesse pushed a commit that referenced this pull request Apr 23, 2023
As described in UTS #46, https://www.unicode.org/reports/tr46

This is working towards OkHttp's own implementation of what
IDN.toASCII() does on the JVM.
swankjesse pushed a commit that referenced this pull request Apr 23, 2023
* Straightforward implementation of IDNA mapping, for tests only

As described in UTS #46, https://www.unicode.org/reports/tr46

This is working towards OkHttp's own implementation of what
IDN.toASCII() does on the JVM.

* Address code review feedback

* Comment the mapping for ¼

* TM should be tm
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants