Ok technically you're right. I am completely wrong when I say it can NEVER happen.
But let's be real here, you introduced DEADLOCKING deliberately by introducing LOCKS and by doing context switching at weird places to make it happen. When nodejs came out one of the selling points was the lack of deadlocks and locks.
Case in point: there are no lock libraries in standard NodeJS.
Think about it, why is a LOCK needed here? Let's say you didn't have locks AT all. Wherever the heck you are the current Node task technically has what is equivalent to a LOCK on everything. Why? because all node instructions are atomic and single threaded. This is what replaces LOCKS in nodejs. Your code example is just strange. The only place where your example is relevant is if there was another process.
>But as a concrete example of where locking is important, consider that I've recently built a dependency injection framework in NodeJS--tried to use others' first, but my situation isn't covered by existing ones--
Probably because, again, nobody really programs using DP in node let alone context switching and adding made up locks in the middle of all these injections and constructions. Whatever you're doing is probably very unique or (maybe, I don't know your specific situation) a sign over engineering. DP is a very bad pattern and is one of the primary sources of technical debt in code (especially when it's over 2 layers deep and in a diamond configuration)... but that's another topic. Anyway...
What is the point of "acquiring" a lock if in node I have a "LOCK" on everything? It makes no sense, whatever it is you're doing I am almost positive that there is a simpler way of doing it. Either way the dependency chain makes it obvious which needs to be created first and what can be created concurrently. The below psuedo code should produce what you're looking for without locks and with equivalent concurrency which is one of the main selling points of single threaded async.
b, c = await runAsync([B, () => C(await D())])
a = await A(b, c)
B is evaluated with D async, C is kickstarted after D, with B still being evaluated async. All of this blocks until both B and C are complete then A evaluates. Whatever the heck you're doing with locks, things should happen in the same order as the dependency chain in both my code and one with locks. There's really no other order these things can be evaluated. I would even argue that my code is indeed the canonical way to handle your diamond problem in node, no lock code needed as expressed by the standard node library.Think about it, node includes high level functions for http but none for locks which are an even lower level concept than http. It must mean you aren't supposed to use locks in Node.
I will say you are technically right in the fact that a deadlock CAN happen. I was wrong in saying it can NEVER happen, but you have to realize that I have a point here. Your example is really going very very far out of the way to pull it off.
>I would also submit that perhaps you should adopt a principle of charity and think real hard about whether your priors are correct before you start talking about what she "fails" to see. Rachel is one of those people who has Been Around and while I also have Been Around, I understand that Rachel has Been Around More and I probably should be listening more than I should be smarming at her.
I was not smarming her, whatever smarming means, I am disagreeing with her just like you are disagreeing with me. There is NOTHING wrong with disagreeing with anybody. What is wrong is when you are proven wrong and you don't accept it. I accept that my statement of a deadlock NEVER happening in nodejs is categorically wrong.
"Being around" does not entitle you to anything. I hate it when people say this, nothing personal. Do you even know how long I've been around? Additionally, the overall main point of my post still stands, which you didn't even really address. I don't think Rachel gets the point of green threads. I think we can both agree I've made a strong point and maybe you should use your own charity principles on me.
Just a thought.