This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (42)
- # asami (13)
- # babashka (40)
- # beginners (25)
- # calva (39)
- # cider (18)
- # circleci (6)
- # cljs-dev (3)
- # clojure (39)
- # clojure-europe (16)
- # clojure-norway (9)
- # clojure-uk (2)
- # clojurescript (42)
- # datalevin (4)
- # datomic (23)
- # fulcro (33)
- # jobs (1)
- # malli (26)
- # minecraft (1)
- # off-topic (88)
- # pedestal (3)
- # polylith (8)
- # re-frame (6)
- # remote-jobs (2)
- # shadow-cljs (20)
- # tools-deps (12)
- # xtdb (5)
I'll answer my own question tomorrow, but i can't remember what core async's behavior in the browser is under the hood. Is it all done against the main thread or are web works, or some other form of thread involved. If not, why not! it seems like browsers are finding ways for userland to do multithreaded work but in limited way. Does that seem right? I suppose i'm not asking about core async in particular here, but more of a general, question about how browsers seem to be changing and how i should be keeping up with those changes.
no. 😛 everything happens in the one and only main thread, no workers. moving stuff into the worker is non trivial since they can't share memory with the main thread and as such would have to serialize/deserialize everything back and forth pretty much killing every performance gain in the process
I'm gonna do that thing people hate. Why aren't they changing, why wouldn't we want multithreading on the browser to?
because retrofitting multi-threading into a JS runtime such as the browser is pretty much impossible
what if we just expose the threaded native runtime to a new type of "browser" 😏
gotcha. What about webassembly?
i suppose i need to read about Service Workers again, as i believe thats what was driving my question. I recall them being very limited, but would in time become more general.
same thing as a regular web worker really, just that it can intercept requests done by the main thread (and other workers) and has a different lifecycle
they are indeed very limited. even more so than regular workers I'd say since they are even more resource constrained
due to their request intercept and lifecycle they can do more than regular workers but IMHO this is pretty much all they should ever be doing
I feel like the docs on service workers told me one thing, and i heard another. > A service worker is a script that your browser runs in the background,
that is the lifecylce I'm refering to yes. you install it and it runs, independent of the page you are on
> Developers mimic 'concurrency' by using techniques like
XMLHttpRequest, and event handlers. Yes, all of these features run asynchronously, but non-blocking doesn't necessarily mean concurrency. Asynchronous events are processed after the current executing script has yielded. The good news is that HTML5 gives us something better than these hacks!
from ~ https://www.html5rocks.com/en/tutorials/workers/basics/
Is the difference between concurrency and asynchronous in this context that we the developer can't control what work is being done on the main thread? e.g stop task A now do task B.
I'm not used to comapring the words directly and its revealing that i don't understand one or the other.
you should probably refer to something more current than July 26th, 2010 when reading about this stuff. this might still be accurate but a lot has happened since 😛
Well thats a link off the top link about service workers. So i guess i'm in good company if i'm confused.
service workers didn't exist in 2010 so you won't find anything about them there. this is just all about generic web workers
i always either go to mozilla or what ever google is calling themselves. Ah, ty for the link.
the main downside of service workers in general is that they are again single threaded. if you do something in them that actually requires CPU time they will block for that time. if a request comes in while that work is happening it has to wait, possibly affecting the UX waiting longer for a request when it maybe didn't need to
Yea. They seem to be a way to schedule work for later, not run it in parallel. I think the use of the term "run in the background" confused me because i assume the "forground" is the main thread. Thanks for the insight as always, i'm going to fall asleep in my chair now. ill look into this a bit more tomorrow.
they are used for coordination of (possibly) all network access so slowing them down in any other way is bad
Is there any way to get the macros for
cljs.test in self hosted (bootstrapped) clojurescript?
And it looks like I can't just analyze
test.cljc from the clojurescript repo myself because it looks like it relies on
clojure.template, which is does not appear to be provided by clojurescript. (Unless I'm missing something.)
i think i've seen this used for
clojure.test/are? Not sure if there are any other usages. Surprised me the first time i saw it
@dpsutton Hmm... I see. I guess that file looks like its technically valid clojurescript.
@dpsutton Yup, looks like plopping those files into https://visr.pl and running them Just worked. So thanks. 🙂