)

package okhttp3

import java.io.IOException
import okhttp3.internal.SuppressSignatureCheck

/** Data classes that correspond to each of the methods of [ConnectionListener]. */
@SuppressSignatureCheck
sealed class ConnectionEvent {
  abstract val timestampNs: Long
  open val connection: Connection?
    get() = null

  /** Returns if the event closes this event, or null if this is no open event. */

cc_library(
    name = "grpc++",
    visibility = ["//visibility:public"],
    deps = select({
        "//conditions:default": ["@com_github_grpc_grpc//:grpc++"],
    }),
)
# copybara:comment_end

# A shared object which includes registration mechanisms for ops and
# kernels. Does not include the implementations of any ops or kernels. Instead,
# the library which loads libtensorflow_framework.so

 * limitations under the License.
 */
package mockwebserver3

/**
 * An adverse action to take on a socket, intended to exercise failure modes in the calling code.
 */
public sealed interface SocketEffect {
  /**
   * Close the TCP socket that carries this request.
   *
   * Using this as [MockResponse.onResponseEnd] is the default for HTTP/1.0.
   */
  public class CloseSocket(

  static void awaitWaiting(Thread t) {
    while (true) {
      Thread.State state = t.getState();
      switch (state) {
        case RUNNABLE:
        case BLOCKED:
          Thread.yield();
          break;
        case WAITING:
          return;
        default:
          throw new AssertionError("unexpected state: " + state);
      }
    }
  }

### Typical Pull Request Workflow -

**1. New PR**

- As a contributor, you submit a New PR on GitHub.
- We inspect every incoming PR and add certain labels to the PR such as `size:`,
  `comp:` etc.  At this stage we check if the PR is valid and meets certain
  quality requirements. For example, we check if the CLA is signed, PR has
  sufficient description, if applicable unit tests are added, if it is a

 */
package jcifs;

import java.net.URLStreamHandler;

/**
 * Encapsulation of client context
 *
 *
 * A context holds the client configuration, shared services as well as the active credentials.
 *
 * Usually you will want to create one context per client configuration and then
 * multiple sub-contexts using different credentials (if necessary).
 *

All source code in Gradle is written to target one or more of these runtimes.
Most source code targets the daemon and the remaining code either targets a single runtime, for example the Gradle client, or is shared across multiple runtimes.

## Composition by architecture modules

Each [architecture module and platform](platforms.md) can contribute code to any of the runtimes.
Not every module contributes to every runtime.

Use dependencies when the logic can't be declared in Pydantic validation, depends on external resources, needs cleanup (with `yield`), or is shared across endpoints.

Apply shared dependencies at the router level via `dependencies=[Depends(...)]`.

## Async vs Sync *path operations*

    </dependencySet>
  </dependencySets>
  <fileSets>
    <fileSet>
      <includes>
        <include>README*</include>
      </includes>
    </fileSet>
    <fileSet>
      <directory>target/maven-shared-archive-resources/META-INF</directory>
      <outputDirectory>./</outputDirectory>
      <includes>
        <include>LICENSE</include>
        <include>NOTICE</include>
      </includes>
    </fileSet>
    <fileSet>

 *
 * <p>An instance may be called concurrently by multiple threads to process different entries.
 * Implementations of this interface should avoid performing blocking calls or synchronizing on
 * shared resources.
 *
 * @param <K> the most general type of keys this listener can listen for; for example {@code Object}
 *     if any key is acceptable