←back to thread

49 points emailed | 1 comments | | HN request time: 0s | source
Show context
wrcwill ◴[] 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 ◴[] 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 ◴[] 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. keeganpoppen ◴[] No.45906736{3}[source]
that isn’t the panacea you describe it to be. you just happen to write a lot of code where writing it that way doesn’t result in consistency problems.