←back to thread

Async and Finaliser Deadlocks

(tratt.net)
49 points emailed | 1 comments | 12 Nov 25 18:12 UTC | HN request time: 0.001s | source
Show context
wrcwill ◴[12 Nov 25 19:14 UTC] No.45904737[source]▶
Unless I'm missing something, this has nothing to do with asynchronous code. The delete is just synchronous code running, same as if we called a function/closure right there.

This is just about syntax sugar hiding function calls.

replies(2): >>45905113 #>>45905158 #
hinkley ◴[12 Nov 25 19:34 UTC] No.45905113[source]▶
I think it says if your async code holds locks you’re gonna have a bad time. Async and optimistic locks probably should go hand in hand.

I would think finalizers and async code magnify problems that are already there.

replies(1): >>45905887 #
cryptonector ◴[12 Nov 25 20:17 UTC] No.45905887[source]▶
If you use a single-threaded executor then you don't need locks in your async code. Well, you might use external locks, but not thread synchronization primitives.

When I write async code I use a single-threaded multi-process pattern. Look ma'! No locks!

Well, that's not very fair. The best async code I've written was embarrassingly parallel, no-sync-needed, read-only stuff. If I was writing an RDBMS I would very much need locks, even if using the single-threaded/multi-processed pattern. But also then my finalizers would mainly drop locks rather than acquire them.

replies(2): >>45906307 #>>45906736 #
1. hinkley ◴[12 Nov 25 20:40 UTC] No.45906307[source]▶
You do have to be careful that all of your data updates are transitive, or you have to hold all of the updates until you can apply them in sequential order. One of my favorite tricks there is to use a throttling or limiting library, start all of the tasks, and then run a for loop to await each answer in order. You still have front-of-line issues but you can make as much forward progress as can be made.