joeycumines
Joined 3 years ago
Karma
39
Submissions
33
Member since
Nov 5
https://github.com/joeycumines
View on Hacker NewsRecent submissions
Comment · 3 years ago
Addendum: My first attempt would drift over time, if the receiver was slow.
Hurt my head a little, but it's fixed now, and I'm at least moderately confident it's correct - unit tested the behavior step by step using `ts-chan`, actually. Will probably use that test as another example use case.
Comment · 3 years ago
Actually, it was fun, so I've made it into an actual package.
The one I slapped together works, but this one is better (fixes issues with actually stopping it properly): https://github.com/joeycumines/generator-ticker
On NPM as generator-ticker.
Comment · 3 years ago
What makes data races not a "real race condition"?
Anyhow, do what you will. I don't get the impression that you are genuinely interested in this topic.
Comment · 3 years ago
Sure do, I haven't actually used this one (I implemented it just then) but it should do the trick: https://gist.github.com/joeycumines/6206f2a6cd79875c7c164738...
Comment · 3 years ago
Generators have lots of really nice uses, yep.
I'm not sure what specifically you were imagining, but I've added an example of how "vanilla JS" can achieve fan-in, using an AsyncGenerator: https://github.com/joeycumines/ts-chan/blob/main/docs/patter...
It uses one of the patterns suggested in a comment chain above, which I think is pretty neat, and wasn't one that readily occurred to me: https://news.ycombinator.com/item?id=38163562
I'm not making a case for using ts-chan for any situation where a simple generator-based solution suffices. I wouldn't call the example solution (in my first link) simple, but it's something I'd personally be ok with maintaining. Like, I'd approve a PR containing something similar without significant qualms, _if_ there was a significant enough motivator, and it was sufficiently unit tested. I might suggest `ts-chan` as an alternative, to make it easier to maintain, but wouldn't be particularly concerned either way.
That's all very subjective, though :)
Comment · 3 years ago
First instalment of docs/examples complete, feedback appreciated: https://news.ycombinator.com/item?id=38183241
Comment · 3 years ago
Concurrency != Parallel execution
Comment · 3 years ago
An operation may take longer than a single tick of the event loop, and may have it's own rules regarding state transitions.
To be clear, I'm not saying "don't do any communication by sharing state", just that there are use cases where it's possible to make it much simpler to reason about.
As an example, you might control the state of "making a HTTP request to perform a search", within the frontend of a single page app that has a map, search filters, and results.
One strategy is to use a buffered channel (1 element), and, when the search filters are updated, drain then re-send the request to the channel.
The logic processing these requests would then just need to sit there, iterating on / receiving from the channel. It could also support cancellation, if that was desired.
(I'd imagine the results would be propagated via some other mechanism, e.g. to a store implementation)
Comment · 3 years ago
I'm working on improving documentation and examples, still a WIP, but you may find this interesting: https://news.ycombinator.com/item?id=38183241
Comment · 3 years ago
Hey HN,
Based on feedback on my last post: https://news.ycombinator.com/item?id=38156519
I've been working on better documentation and examples, aimed at JavaScript developers without significant knowledge of concurrency-related patterns.
The first pattern I've covered is "fan-in". Aside from a side-by-side comparison, in the pattern doc linked in the question, I also implemented an example of the pattern, a "log aggregator", which multiplexes (TCP) log streams, formatting and writing out lines to a file. Details in the example readme: https://github.com/joeycumines/ts-chan/blob/main/examples/pa...
I'd appreciate it if you could let me know what you think, and if this is a step in a helpful direction.
Thanks :)
Comment · 3 years ago
Hey, that's a neat little trick to implement locking in JS, thanks.
I oversimplified my example perhaps - it also involved handling interruptions (certain system events), maintaining a lifecycle (set up and tear down), and scenarios where it allowed a certain subset of operations to be performed, while performing one of several operations. That last requirement was due to it using shell scripts to perform configuration of the system, and it needing to extract runtime and configuration information from the main daemon.
Still though, thanks very much for your comments, I've enjoyed reading them.