*
     * <p>Note that this method is not necessarily called immediately before one of the visit methods, as some collections may be
     * resolved in parallel. However, all visiting is performed sequentially and in order.
     * This method is also called sequentially and in order.
     *
     * @return how should the collection be visited?
     */
    default VisitType prepareForVisit(FileCollectionInternal.Source source) {

 * methods willed be called sequentially in the following order:
 *
 * - {@link RemoteTestClassProcessor#startProcessing()}
 * - 0 or more calls to {@link RemoteTestClassProcessor#processTestClass(TestClassRunInfo)}
 * - {@link RemoteTestClassProcessor#stop()}
 *
 * Commands are received on communication threads and then processed sequentially on the main thread.  Although concurrent calls to

in this package, and they're replaced with platform-specific intrinsics.
On other platforms, generic implementations are made available.

Unless otherwise noted, operations defined in this package are sequentially
consistent across threads with respect to the values they manipulate. More
specifically, operations that happen in a specific order on one thread,
will always be observed to happen in exactly that order by another thread.
*/

 * provider.
 *
 * Composable providers share certain traits: There is a notion of a sequentially composed [KotlinCompositeProvider] of that kind, and there
 * is usually a merge function which allows to create a single provider from a list of providers. Mergers of composable providers may
 * produce a merged provider which is more efficient than the naive sequential composite provider.
 *

 * Promote to a more shared subproject if useful.
 */
public abstract class Combiners {

    /**
     * We know the stream we are processing is handled sequentially, and hence there is no need for a combiner.
     */
    public static <T> BinaryOperator<T> nonCombining() {
        return Combiners::unsupportedCombineOperation;
    }

//	                      Out                                    Out                            Out
//
// The pluginwatcher module follows strictly and sequentially this state machine for each *plugin name*.
// e.g: If you are Registering a plugin foo, you cannot get a DeRegister call for plugin foo

// license that can be found in the LICENSE file.

package par

import "fmt"

// Queue manages a set of work items to be executed in parallel. The number of
// active work items is limited, and excess items are queued sequentially.
type Queue struct {
	maxActive int
	st        chan queueState
}

type queueState struct {
	active  int // number of goroutines processing work; always nonzero when len(backlog) > 0
	backlog []func()

	}
	mr.readers = nil
	return sum, nil
}

var _ WriterTo = (*multiReader)(nil)

// MultiReader returns a Reader that's the logical concatenation of
// the provided input readers. They're read sequentially. Once all
// inputs have returned EOF, Read will return EOF.  If any of the readers
// return a non-nil, non-EOF error, Read will return that error.
func MultiReader(readers ...Reader) Reader {

then <i>A</i> is synchronized before <i>B</i>.
All the atomic operations executed in a program behave as though executed
in some sequentially consistent order.
</p>

<p>
The preceding definition has the same semantics as C++’s sequentially consistent atomics
and Java’s <code>volatile</code> variables.
</p>

<h3 id="finalizer">Finalizers</h3>

<p>

   * Different orderings for combining the elements of an input array, which must all produce the
   * same result.
   */
  enum CollectStrategy {
    /** Get one accumulator and accumulate the elements into it sequentially. */
    SEQUENTIAL {
      @Override
      final <T extends @Nullable Object, A extends @Nullable Object, R extends @Nullable Object>
          A result(Collector<T, A, R> collector, Iterable<T> inputs) {