Be careful with this, though. If a promise is expected to resolve and it never does, and the promise needs to resolve or reject to clean up a global reference (like an event listener or interval), you'll create a memory leak. It's easy to end up with a leak that's almost impossible to track down, because there isn't something obvious you can grep for.
You can't cancel a JavaScript promise (except sometimes you can)
31–40 of 66 posts
Re: You can't cancel a JavaScript promise (except sometimes you can)
#32Be careful with this, though. If a promise is expected to resolve and it never does, and the promise needs to resolve or reject to clean up a global reference (like an event listener or interval), you'll create a memory leak. It's easy to end up with a leak that's almost impossible to track down, because there isn't something obvious you can grep for.
This is addressed at the end of the article:
The catch
You're relying on garbage collection, which is nondeterministic. You don't get to know when the suspended function is collected. For our use case, that's fine. We only need to know that it will be collected, and modern engines are reliable about that.
The real footgun is reference chains. If anything holds a reference to the hanging promise or the suspended function's closure, the garbage collector can't touch it. The pattern only works when you intentionally sever all references.Re: You can't cancel a JavaScript promise (except sometimes you can)
#33You can also race it with another promise, which e.g. resolves on timeout.
You can but it still won't get cancelled. I found out when I tried to implement a hard time limit to a call.
Re: You can't cancel a JavaScript promise (except sometimes you can)
#34I like how C# handles this. You're not forced to support cancellation, but it's strongly encouraged. The APIs all take a CancellationToken, which is driven by a CancellationTokenSource from the ultimate caller. This can then either be manually checked, or when you call a library API it will notice and throw an OperationCancelledException. Edit: note that there is a "wrong" way to do this as well. The Java thread libr…
> "Cooperative" (as opposed to preemptive) cancel is much cleaner.
Which what Thread.interrupt does.
Re: You can't cancel a JavaScript promise (except sometimes you can)
#35I like how C# handles this. You're not forced to support cancellation, but it's strongly encouraged. The APIs all take a CancellationToken, which is driven by a CancellationTokenSource from the ultimate caller. This can then either be manually checked, or when you call a library API it will notice and throw an OperationCancelledException. Edit: note that there is a "wrong" way to do this as well. The Java thread libr…
I am surprised that you had to go out of your way to remove Thread.stop from existing Java code. It's been deprecated since 1998, and the javadoc page explains pretty clearly why it's inherently unsafe. It's hard to miss all the warnings unless you're literally just looking at the method name and nothing else.
That’s barely-junior interview question indeed.
Re: You can't cancel a JavaScript promise (except sometimes you can)
#36I like how C# handles this. You're not forced to support cancellation, but it's strongly encouraged. The APIs all take a CancellationToken, which is driven by a CancellationTokenSource from the ultimate caller. This can then either be manually checked, or when you call a library API it will notice and throw an OperationCancelledException. Edit: note that there is a "wrong" way to do this as well. The Java thread libr…
I don't like it - you're forced to pass around this token, constantly manage the lifecycle of cancellation sources - and incredibly bug prone thing in async context, and it quickly gets very confusing when you have multiple tokens/sources.
I understand why they did it - a promise essentially is just some code, and a callback that will be triggered by someone at some point in time - you obviously get no quality of service promises on what happens if you cancel a promise, unless you as a dev take care to offer some.
It's also obvious that some operations are not necessarily designed to be cancellable - imagine a 'delete user' request - you cancelled it, now do you still have a user? Maybe, maybe you have some cruft lying around.
But still, other than the obvious wrong solution - C# had a Thread.Abort() similar to the stop() function that you mentioned, that was basically excommunicated from .NET more then a decade ago, I'm still not happy with the right one.
Re: You can't cancel a JavaScript promise (except sometimes you can)
#37I soft of feel like every five years someone comes along and tries to re-invent cancellable threads and immediately arrives back at the same conclusion: the problem of what it means to "cancel" a thread is so domain-specific that you never save anything trying to "support" it in your threading framework; you try and save people the effort of doing something ad-hoc to simulate cancellation and build something at least as complicated as what they would build ad-hoc, because thread cancellation is too intimately tied to the problem domain the threads are operating on to generalize it.
Re: You can't cancel a JavaScript promise (except sometimes you can)
#38Ten years ago, I was an acid reader of the tc39 (EcmaScript standard committee) mailing list and cancelable promises used to be the hot topic for a while.
I unsubscribed at some point because I wasn't working with JavaScript this much, but it's disappointing to see that this work has gone nowhere in the meantime.
I like how Rust futures are canceled by dropping them, even though it's also a footgun (though IMHO this is more of a problem with the select! pattern than with drop-to-cancel proper).
Re: You can't cancel a JavaScript promise (except sometimes you can)
#39Re: You can't cancel a JavaScript promise (except sometimes you can)
#40I like how C# handles this. You're not forced to support cancellation, but it's strongly encouraged. The APIs all take a CancellationToken, which is driven by a CancellationTokenSource from the ultimate caller. This can then either be manually checked, or when you call a library API it will notice and throw an OperationCancelledException. Edit: note that there is a "wrong" way to do this as well. The Java thread libr…
I don't like it - you're forced to pass around this token, constantly manage the lifecycle of cancellation sources - and incredibly bug prone thing in async context, and it quickly gets very confusing when you have multiple tokens/sources. I understand why they did it - a promise essentially is just some code, and a callback that will be triggered by someone at some point in time - you obviously get no quality of ser…
> ...constantly manage the lifecycle of cancellation sources
Usually, you are passing through a runtime provided token (e.g. ASP.NET).