This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (2)
- # arachne (1)
- # beginners (5)
- # boot (33)
- # cider (12)
- # cljs-dev (6)
- # cljsrn (26)
- # clojure (33)
- # clojure-austin (7)
- # clojure-belgium (6)
- # clojure-chicago (1)
- # clojure-dusseldorf (1)
- # clojure-fr (1)
- # clojure-hamburg (1)
- # clojure-nl (11)
- # clojure-portugal (3)
- # clojure-russia (14)
- # clojure-spec (35)
- # clojure-uk (28)
- # clojurescript (49)
- # component (7)
- # core-async (75)
- # cursive (13)
- # datomic (15)
- # dirac (57)
- # emacs (5)
- # events (1)
- # hoplon (34)
- # jobs (2)
- # jobs-discuss (8)
- # lambdaisland (1)
- # lein-figwheel (7)
- # leiningen (3)
- # om (5)
- # onyx (8)
- # re-frame (56)
- # reagent (13)
- # testing (7)
- # untangled (30)
- # vim (51)
- # yada (17)
if I run the relevant code in a
lein figwheel REPL, it works fine. Just... not in cider's nrepl.
According to google the rhino js engine doesn't include the setTimeout function (like the error says), which is what core.async uses to run tasks
Yeah, IIRC we never tested core.async in Rhino. Wouldn't be hard to add support we'd just need some sort of function like setTimeout.
I have this thing called "cache" that is a caching abstraction. When I tell the cache to return something, if it can't find it inside itself it will ask a server for it. If i tell the cache to write something to itself, it will actually tell a server to write something and wait for an "ok" response before commit it to itself. Writes generally take a while, but reads could return super quickly or they could also take awhile. So would it be inappropriate to use go blocks here? Should I use threads? And why?
@bcbradley If you perform a blocking operation in a go block, you’ll consume one of the threads in the core.async thread pool for the duration of that operation.
if you perform a blocking operation on a real thread, you'll consume a real thread though won't you?
i suppose if you have 8 real threads and only back the thread pool with 4 of them, then by using thread instead of go you'll be using threads you wouldn't otherwise use, and you won't slow down your thread pool
And if you tie up that pool with blocking operations, pretty much all core.async operations are blocked.
i don't even see how you can block on even a single thread that backs it if you use go'
i'm sorry if i'm being combative i'm just trying to understand when and why to use thread vs go
@bcbradley if it's asynchornous (non-blocking / event-driven / etc.) use
go. If it blocks, use
if you are block on anything besides reading or writing to a channel, then don't use
here is the overview of my architecture: you use http RESTful things like GET POST DELETE etc on an abstraction called a "cache". If the cache finds what you are looking for inside of it (via GET), it will just return that. If it can't do the operation on itself because it can't find it it will call the server. If it can't do the operation because it is a mutation it will call the server. In any case, these commands are "fire and forget", the cache is responsible for updating itself via the server in response to commands.
In order to program in this model, the user makes "callbacks" that fire when the cache changes in a specific way
Use go blocks for everything, and when you need to make a call to a remote server use async http (or whatever your protocol is).
so let me get this straight-- if you perform long blocking operations in a go block, it will park one of the tasks that the thread pool is responsible for executing. They will continue to execute other tasks, but presumably come back periodically to "check up" on the status of the long blocking task. If you do this for lots of tasks in that thread pool, a lot of the work being done by the thread pool will be "check up" work, reducing efficiency
If you perform IO inside a go block it will block the thread executing the go block. Do that more than the number of go block threads (defaults to 8) and you can deadlock your program.
go blocks only "park" when reading or writing to a channel, and parking is the only thing that causes a go block to yield so other go blocks can execute on the threadpool go blocks execute on
if it is doing anything useful at all being there, it won't block most of the time for read operations
If you use an async HTTP client library you can make the whole stack async. And that may integrate cleaner if the user of your library is also using an async stack (like a Pedestal web server).
But it all depends on the number of API calls you expect, overall throughput, system resource constraints, etc.
@tbaldridge thanks for the advice! After looking for an asynchronous library I think http-kit is probably the best fit (was using clj-http)
> You can jack into Figwheel from emacs though right?
so from a command line, I do
lein figwheel, and then emacs can jack in to that? That sounds incredible, could you link to a resource or something please, that explains how to do that? (i'm a bit new)
sure, @josh.freckleton IIRC firstly you need to add
:nrepl-port 7002 to your figwheel config. Then you can (from within emacs) run
cider localhost:7002 to connect to the CLJS repl.
It is possible, sadly I haven't used Figwheel in about a year and cider in about 2 years, so I may have some of the configs wrong.
I'm OT now, but this might have more info: https://markhudnall.com/2016/04/25/starting-figwheel-in-emacs/
so, you don't use cider? Do you use something else? I mean, the quick feedback loop is a big reason i love clj, i'm wondering if there's an alternative that's on the rise...