undefined | Better HN

0 pointstgv6y ago0 comments

> We're not talking about multicore/singlecore stuff.

If you write a python or nodejs handler, stateless or not, that does two subsequent async operations involving changes on shared resources, such as a database table, you need locks, because another request may come in while the first is in wait.

Perhaps you try to say that this is irrelevant when you allow only one request at a time, but that's extremely limited and not the scenario under discussion.

0 comments

crimsonalucard6y ago

Nah I'm saying in the web application itself you shouldn't handle it. Python async/await or NodeJS.

You have to deal with deadlocks and race condition stuff in operations to the DB or any shared muteable state. That is obvious, but that is an external issue because web developers deal with shared muteable state as an external service that lives outside of python or nodejs code.

I mean if you count the transaction string or orm as part of dealing with locks within your web framework, then sure, I guess you're right? The locks on the DB are DB primitives though and not part of the web framework of language so I would argue that it's different. I guess reordering updates to happen on primitives in the same order could count as a web application change, but that's kind of weak as you're not really addressing the point:

NodeJS doesn't have locks, because you don't need locks in NodeJS and a deadlock should not occur unless you deliberately induce it.

The overall argument is the framework of NodeJS and python async/await is not designed for that kind of shared muteable state hence the lack of locks in nodejs std.

Also, never did I say a web developer doesn't need to understand or deal with concurrency. This is not true and I never claimed otherwise.

Additionally thank you for being respectful. (Take note eropple)

eropple6y ago

This is a really important point. Exporting your locks to Postgres mean neither that they stop existing nor that you can’t wedge if it’s not written by clever programmers who better understand concurrency.

crimsonalucard6y ago

Yes it is an important point. Postgresql does not stop deadlocks or race conditions from happening. You deal with those in Postgresql.

But this isn't the topic of the conversation is it? The topic is locks and deadlocks in Python asyncio and NodeJS so ultimately irrelevant to your initial example of the amateur diamond dependency injection where normally no deadlock should be occuring regardless.

eropple6y ago

[I edited my post before his reply. Sorry for the confusion.]

Exporting your race conditions and washing your hands of them because the lock mechanism lives on the other end of a network socket rather than in your process space does not even rise to the level of “mere semantics”.

If you allow two NodeJS fibers to acquire remote locks—Redis redlocks, whatever—out of order by way of making asynchronous requests to it (noted only because you have a curious grip on that as being distinctive or meaningful here), you’ve still deadlocked and it is for all meaningful distinctions a deadlock of your processes (N >= 1). I state this only for completeness; there is no magic border at the edge of your process in which no, no, locks do not happen here. Locks control concurrency. When the problem set requires them, you use them.

I do not understand the spam of capital letters or the weird aggression. It’s like arguing about the coefficient of friction. The thing speaks for itself.

1 more reply

j / k navigate · click thread line to collapse

0 comments

crimsonalucard6y ago

Nah I'm saying in the web application itself you shouldn't handle it. Python async/await or NodeJS.

NodeJS doesn't have locks, because you don't need locks in NodeJS and a deadlock should not occur unless you deliberately induce it.

The overall argument is the framework of NodeJS and python async/await is not designed for that kind of shared muteable state hence the lack of locks in nodejs std.

Also, never did I say a web developer doesn't need to understand or deal with concurrency. This is not true and I never claimed otherwise.

Additionally thank you for being respectful. (Take note eropple)

eropple6y ago

crimsonalucard6y ago

Yes it is an important point. Postgresql does not stop deadlocks or race conditions from happening. You deal with those in Postgresql.

eropple6y ago

[I edited my post before his reply. Sorry for the confusion.]

I do not understand the spam of capital letters or the weird aggression. It’s like arguing about the coefficient of friction. The thing speaks for itself.

1 more reply

j / k navigate · click thread line to collapse