I enjoy diagnosing concurrency issues and thinking about what principles I could use to avoid similar issues in future.
Two principles that are relevant to this example are:
1. Reduce the number of places a lock is acquired.
2. Reduce the scope of locks.
(1) would suggest two potential improvements:
a. broadcastToStream shouldn't take the lock at "First, we check if we have a particular stream, if not, we return.". Leave the stream existence check to the go pool. This would have avoided the issue but could cause more contention on the GoPool in the case of unrecognised stream names, which might not be acceptable.
b. Don't acquire the lock in the go pool function within broadcastToStream. Rather, find the list of clients within broadcastToStream, and refer to that within the Go pool function. This also might not be acceptable, depending on hoe the lifetime of client and hub related: clients could receive messages after an unsubscribe.
(2) would suggest the fix you made.
That said, hindsight is 20:20 and I expect I'd make similar bug.
> Lisp guys have nothing to sell you but probably the software they create. And if they have a powerful tool, they are not that interested on you knowing their secret.
This level of claim is indistinguishable from fiction.
> "... by individuals and small communities" almost invariably means "by experienced developers who want a playground."
I acknowledge this.
> "Why should an ordinary user care about this?" isn't asked nearly as often as it should be. And "Don't you understand the tech is fun to play with?" is not the right answer.
I have spoken to friends and family and they are perfectly happy with their mainstream computing choices.
I acknowledge that my preference for back-to-basics is partly due to fun. I'm not trying to change minds. I enjoy this small paradise for hackers.
> Although I like the spirit of this idea, I don't know that I could trust it in practice as it will be companies like Google, Amazon, and Microsoft that own the actual hardware.
This is the point that the author makes in the second part of their post. Quote:
"The dutifully critical part of me wants to shout: you shouldn’t trust these slabs! Their operators, G — and A — and M — and the rest, will surely betray you. The very signature of the corporate internet is the way it slips from your grasp. The leviathans swim off in pursuit new markets, and what do they leave you with? Deprecation notices."
I see this trend too: the systems powering the modern world are increasingly featureful, complicated, centralised into a few hands, and this will likely continue.
I'm a keen developer and user in this world, and recognize the vast users this world provides for.
At the same time, I appreciate a back-to-basics approach that emphasizes systems that can be understood and controlled by individuals and small communities:
* Hardware that has open specs: Pinephone, Pinebook, Raspberry Pi, ...
* Open source OSs: Linux desktop, Linux mobile, Lineage OS.
I enjoy diagnosing concurrency issues and thinking about what principles I could use to avoid similar issues in future.
Two principles that are relevant to this example are: 1. Reduce the number of places a lock is acquired. 2. Reduce the scope of locks.
(1) would suggest two potential improvements:
a. broadcastToStream shouldn't take the lock at "First, we check if we have a particular stream, if not, we return.". Leave the stream existence check to the go pool. This would have avoided the issue but could cause more contention on the GoPool in the case of unrecognised stream names, which might not be acceptable.
b. Don't acquire the lock in the go pool function within broadcastToStream. Rather, find the list of clients within broadcastToStream, and refer to that within the Go pool function. This also might not be acceptable, depending on hoe the lifetime of client and hub related: clients could receive messages after an unsubscribe.
(2) would suggest the fix you made.
That said, hindsight is 20:20 and I expect I'd make similar bug.