clintropolis commented on code in PR #19397:
URL: https://github.com/apache/druid/pull/19397#discussion_r3206343297


##########
processing/src/main/java/org/apache/druid/segment/AsyncCursorHolder.java:
##########
@@ -0,0 +1,298 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.druid.segment;
+
+import com.google.errorprone.annotations.concurrent.GuardedBy;
+import org.apache.druid.error.DruidException;
+import org.apache.druid.frame.processor.ReturnOrAwait;
+import org.apache.druid.java.util.common.Either;
+
+import javax.annotation.Nullable;
+import java.io.Closeable;
+import java.util.ArrayList;
+import java.util.List;
+
+/**
+ * Closeable wrapper around an asynchronously-loaded {@link CursorHolder}, 
returned by
+ * {@link CursorFactory#makeCursorHolderAsync}. Designed to make lifecycle 
management safe even when the holder is
+ * still loading: callers receive a single Closeable handle and can register 
it once with their cleanup machinery,
+ * regardless of where the underlying load is in its lifecycle.
+ * <p>
+ * The hazard this exists to avoid: returning a {@code 
ListenableFuture<CursorHolder>} (or similar future-of-Closeable)
+ * makes correct cleanup error-prone, where canceling the future or letting a 
caller fail before consuming the future
+ * can orphan the produced holder, leaking the underlying resources. By 
exposing a Closeable that internally tracks the
+ * load and disposes whatever has materialized, callers don't have to write 
that bookkeeping themselves.
+ * <p>
+ * <h3>Producer protocol</h3>
+ * Producers feed results in via {@link #set(CursorHolder)} or {@link 
#setException(Throwable)}, both of which return
+ * a boolean. If they return {@code false}, this wrapper has already been 
closed and the producer is responsible for
+ * closing whatever holder it just produced.
+ * Producers may pass a {@link Runnable} canceler at construction time which 
runs on {@link #close()} when the wrapper
+ * is closed before the {@link #set} has been called, giving the producer an 
opportunity to abort its work. The canceler
+ * is best-effort: a producer may have already produced the holder by the time 
it observes cancellation, in which case
+ * its {@link #set} call will return false and it must close the holder it 
tried to set.
+ * <p>
+ * <h3>Consumer protocol</h3>
+ * Consumers wait for {@link #isReady()} via {@link #addReadyCallback}, and 
{@link #release()} to transfer ownership of
+ * the {@link CursorHolder} (or throw the producer exception). Calling {@link 
#release()} before {@link #isReady()}
+ * returns {@code true}, multiple times, or after this holder has been closed 
will throw a {@link DruidException}.
+ * <p>
+ * For example (using {@link ReturnOrAwait} to show intended yield-then-resume 
usage pattern):
+ * <pre>{@code
+ * if (asyncHolder == null) {
+ *     asyncHolder = cursorFactory.makeCursorHolderAsync(spec);
+ *     closer.register(asyncHolder);  // safe at any lifecycle point, close() 
handles in-flight loads
+ * }
+ * if (!asyncHolder.isReady()) {
+ *     SettableFuture<?> awaitFuture = SettableFuture.create();
+ *     asyncHolder.addReadyCallback(() -> awaitFuture.set(null));
+ *     return ReturnOrAwait.awaitAllFutures(List.of(awaitFuture));
+ * }
+ * final CursorHolder holder = asyncHolder.release();  // ownership transfers 
to the caller
+ * // ... use holder; close it when done (or hand it to a component that owns 
its lifecycle) ...
+ * }</pre>
+ */
+public class AsyncCursorHolder implements Closeable
+{
+  /**
+   * Completed {@link AsyncCursorHolder} backed by an already available {@link 
CursorHolder}
+   */
+  public static AsyncCursorHolder completed(CursorHolder holder)
+  {
+    final AsyncCursorHolder result = new AsyncCursorHolder(null);
+    result.set(holder);
+    return result;
+  }
+
+  @Nullable
+  private final Runnable canceler;
+
+  @GuardedBy("this")
+  @Nullable
+  private CursorHolder result = null;
+  @GuardedBy("this")
+  @Nullable
+  private Throwable error = null;
+  @GuardedBy("this")
+  private boolean closed = false;
+  @GuardedBy("this")
+  private boolean disposed = false;
+  @GuardedBy("this")
+  private final List<Runnable> readyCallbacks = new ArrayList<>();
+
+  /**
+   * @param canceler optional callback invoked from {@link #close()} when the 
wrapper is closed before the load has
+   *                 completed ({@link #set} or {@link #setException}). 
Producers that support cancellation should
+   *                 provide one; producers that don't can pass {@code null}, 
in which case {@link #close()} just stops
+   *                 observing the result.
+   */
+  public AsyncCursorHolder(@Nullable Runnable canceler)
+  {
+    this.canceler = canceler;
+  }
+
+  /**
+   * Allows producer to mark the load successful with the given holder. 
Returns {@code true} if accepted, {@code false}
+   * if this wrapper has already been closed, in which case the producer is 
responsible for closing {@link CursorHolder}
+   * itself. Throws {@link DruidException} if the load was already completed 
(from prior calls to this method or
+   * {@link #setException}).
+   * <p>
+   * Callbacks registered via {@link #addReadyCallback} fire outside the lock 
to avoid re-entrancy deadlocks.

Review Comment:
   oh, i guess bad wording; like its more like avoiding problems like if the 
callback needs to hold some other lock we don't have any weird ordering issues 
like if that lock is some lock shared between callback thread and producing 
thread, will try to clarify



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to