Github user tdas commented on a diff in the pull request:
    --- Diff: core/src/main/scala/org/apache/spark/util/ManualClock.scala ---
    @@ -27,6 +27,7 @@ package org.apache.spark.util
     private[spark] class ManualClock(private var time: Long) extends Clock {
       private var _isWaiting = false
    +  private var _readyForFirstPeek = false
    --- End diff --
    I think semantically this ManualClock is becoming a very complex and 
confusing API to use. The caller has to 
    How about changing the API to something like this. 
    - ManualClock: It has a method called 
`isThreadWaitingAt(timeWhenWaitStarted: Long): Boolean`. It returns true when 
another thread has started waiting when the time was `timeWhenWaitStarted`. 
This replaces `isWaiting`.
    - StreamTest: It keeps track of the expected time when manual clock is 
being used. For every AdvaneManualClock is first calls 
`isThreadWaitingAt(expectedTime)` until it returns true, then advances manual 
clock as well as the expected time.
    This will ensure that successive AdvanceManualClock will wait for the 
StreamExecution thread to be unblocked from the previous wait, and start a new 
wait on the expected time.
    How does this sound?
    If this sounds good, then there should be unit tests to test this Manual 
Clock behavior thoroughly.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to