Ceylon 1.3.3 Future timeout cancellation: JVM vs JavaScript backend differences

Direct answer

No. In Ceylon 1.3.3, orElseAfter gives you a deadline for the result, not a guarantee that the timed-out computation has stopped. The returned future completes with the fallback once the delay elapses. Any cancellation of the original future is a request forwarded to the executor; it is not evidence that the task has terminated. That holds on both the JVM and JavaScript backends.

What the timeout actually does

Treat orElseAfter as a race between two futures: the original and a delayed fallback. When the delay wins, the implementation asks the original future to cancel — on the JVM this is typically an interrupt-style request, on JavaScript a flag or promise rejection. In both cases the request is cooperative, and the executor decides what, if anything, happens next.

JVM backend

• An interrupt-style cancel(true) can unblock operations defined to respond to interruption, such as Thread.sleep, Object.wait, and interruptible channel operations.
• It cannot force arbitrary CPU-bound code to stop. A loop that never checks interruption or a cancellation flag runs to completion.
• Libraries sometimes catch and swallow interruption, so behavior varies per blocking call.

JavaScript backend

• There is no thread to interrupt. A timeout callback cannot preempt running synchronous code.
• The callback runs only when the event loop is free, so a long synchronous computation delays the timeout itself, not just the cancellation.
• Cancellation can at best set a flag or reject a promise; the running computation continues unless it checks.

When does isCancelled() become true?

isCancelled() reports that a cancellation request was recorded, not that the task stopped. It can lag behind the deadline because the timeout callback is itself scheduled work. On the JVM the lag is usually short; on JavaScript, synchronous work can push it out arbitrarily. Do not use it as a completion signal.

Getting deterministic cleanup

There is no portable, documented guarantee of deterministic termination across backends. Determinism has to come from your own code:

1. Check a cancellation flag or interruption at safe points in long-running loops.
2. Release sockets, locks, and handles in finally blocks rather than after the timeout.
3. Prefer blocking calls documented to respond to interruption on the JVM.
4. On JavaScript, make async work cancellation-aware and avoid long synchronous stretches.

Illustrative pseudocode — adjust to the actual 1.3.3 signatures in your SDK:

value work = startAsync(() {
    while (!token.cancelled) {   // cooperative checkpoint
        processOneChunk();
    }
});
value result = work.orElseAfter(deadline, fallback);

The fallback completing tells you the deadline passed. It does not tell you the loop above exited.

Verification you can run

1. Locate the ceylon.concurrent sources shipped with your Ceylon 1.3.3 distribution and read the orElseAfter and cancel paths for both backends.
2. On the JVM, run one task that sleeps and one that spins in a CPU-bound loop. Log when isCancelled() flips and when the task body actually exits.
3. On JavaScript, run a long synchronous loop and a timer-based task. Observe whether the timeout callback fires during the synchronous loop.
4. Log a finally block after a timeout to see whether cleanup runs promptly or waits for the task to finish.

Because executor behavior dominates here, confirm findings against the specific executor you use rather than assuming the results generalize.

One detail that changes the recommendation

Which executor runs the timed-out tasks? If it is a thread pool whose tasks are interruptible, cooperative checks plus finally cleanup are usually enough. If it is a single-threaded or event-loop executor — typical on JavaScript — no timeout can preempt the work, and you must design the task to yield and check cancellation itself.