Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You can't cancel a JavaScript promise (except sometimes you can)

inngest.com

Post reply on HN
Print view View original

41–50 of 66 posts

Re: You can't cancel a JavaScript promise (except sometimes you can)

#41

Post by bastawhiz »

hungryhobbit wrote: post #32
bastawhiz wrote: post #31

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.

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 funct…

That should honestly be much higher up and much more clearly spelled out.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#42

Post by AtlasBarfed »

teraflop wrote: post #18
pjc50 wrote: post #6

I 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.

One of Java's the ecosystem fundamental platforms is that it's multi-threading. It's gone through too many models.

And since Java has a metric ton of blog posts from the 2000s and 2010s, a lot of search engines lead you to older models.java itself has gone from green threads to OS threads and back to green threads now.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#44

Post by kelnos »

teraflop wrote: post #18
pjc50 wrote: post #6

I 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.

Not to mention that I feel like it's pretty unusual to be creating and managing threads yourself in Java these days, instead of using a thread pool/executor.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#45

Post by torginus »

CharlieDigital wrote: post #40
torginus wrote: post #36

Earlier quoted context omitted.

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 Very rare unless you are spawning your own. Usually, you are passing through a runtime provided token (e.g. ASP.NET).

Not that rare in my experience, I constantly had to write software like this. Not every day, but it certainly did come up quite often in my code and others'

Oh and oone more thing - the very (developer-managed) complexity makes it that people constantly got it wrong, usually just enough (as often with the case of threading) that it worked fine 90% of the time, and was very hard to make a case to management why we should invest effort into fixing it.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#46

Post by notnullorvoid »

runarberg wrote: post #16
esprehn wrote: post #14

Earlier quoted context omitted.

AbortSignal is same thing on the Web. It's unfortunate TC39 failed to ever bring a CancelToken to the language to standardize the pattern outside browsers.

TC39 seems to be failing at many things for the past 10 years.

Hard disagree, TC39 has done great work over the last 10 years. To name a few: - Async/await - Rest/spread - Async iterators - WeakRefs - Explicit Resource Management - Temporal

It's decisions are much more well thought out than WHATWG standards. AbortSignal extending from EventTarget was a terrible call.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#47

Post by fragmede »

shadowgovt wrote: post #37

I 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…

But what if we add another layer of indirection.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#48

Post by cowboyd »

Is it safe to just "stop calling next() on a generator?" like the post suggest?

To me that sounds like dropping the task on the floor. Specifically, this will not invoke any finally {} blocks:

More correctly, you should invoke `return()` on the generator. Otherwise, you won't provide execution guarantees. This is how Effection does it. There is no equivalent in async functions, so it sounds like the same problem would apply to the GC technique.

Re: You can't cancel a JavaScript promise (except sometimes you can)

#50

Post by bakkoting »

esprehn wrote: post #14
pjc50 wrote: post #6

I 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…

AbortSignal is same thing on the Web. It's unfortunate TC39 failed to ever bring a CancelToken to the language to standardize the pattern outside browsers.

Browsers have said that they are unwilling to ship any new cancelation mechanisms given that AbortSignal already exists, so we can't ship a different CancelToken. But I think there's a path to standardizing a subset of the existing AbortSignal machinery [1].

(I am on TC39 and while this isn't my highest priority I did bring the topic for discussion at the last meeting [2], and there was support from the rest of committee.)

[1] https://github.com/tc39/proposal-concurrency-control/issues/...

[2] https://github.com/bakkot/structured-concurrency-for-js

Post reply on HN