mleku on Nostr: gawd, this subscription listener thing in this code is so written wrong firstly, it ...
gawd, this subscription listener thing in this code is so written wrong
firstly, it is using maps, which means mutexes, those aren't necessary for reading, and the actual websockets that are part of the map... have their own mutex on their functions so there is actually no need for this
so after fighting with this for the last day, i'm just gonna refactor this progressively
first is removing those maps and mutexes, that are unnecessary
they are just a lazy way to deal with removing elements of an array, but in Go that laziness means mutexes and it means less efficient concurrency, the array can be concurrently read, this is not a problem!
then once i have converted the lists of subscribers and their contained subscription IDs i can then make the structure common with the http except with the difference of a second interface that handles accessing the actual socket and id of each of the elements, which doesn't need to be done for the http one because it only does one filter one request
the last part is that the websocket has a context that closes same as the http.Request, so i will probably want to unify that somehow
this architecture is ugly, really ugly, like a classic bulgarian commieblock
Published at
2025-04-13 10:27:57Event JSON
{
"id": "5a095e7abe53644090d67d2cd81358c5f43725945381850322bf8d294d78a7f2",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1744540077,
"kind": 1,
"tags": [
[
"client",
"jumble"
]
],
"content": "gawd, this subscription listener thing in this code is so written wrong\n\nfirstly, it is using maps, which means mutexes, those aren't necessary for reading, and the actual websockets that are part of the map... have their own mutex on their functions so there is actually no need for this\n\nso after fighting with this for the last day, i'm just gonna refactor this progressively\n\nfirst is removing those maps and mutexes, that are unnecessary\n\nthey are just a lazy way to deal with removing elements of an array, but in Go that laziness means mutexes and it means less efficient concurrency, the array can be concurrently read, this is not a problem!\n\nthen once i have converted the lists of subscribers and their contained subscription IDs i can then make the structure common with the http except with the difference of a second interface that handles accessing the actual socket and id of each of the elements, which doesn't need to be done for the http one because it only does one filter one request\n\nthe last part is that the websocket has a context that closes same as the http.Request, so i will probably want to unify that somehow\n\nthis architecture is ugly, really ugly, like a classic bulgarian commieblock",
"sig": "65ac33ee2bfda12fd373a25fb5b24491c818eae27c012d638e0a903be0b6f2581cfd1f17eaa80635709b84c8d0c1e10baf4e131ccb871721dd91bab315214088"
}