i'm running this in emacs using CIDER

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.

@hiredman @tbaldridge thanks! So, I prob just won't test CLJS from within emacs for now 🙂

yeah figwheel is so nice I never really made Rhino much of a priority.

You can jack into Figwheel from emacs though right?

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?

and isn't the thread pool backed by real threads?

Yes, you’ll consume a real thread.

Buuuuut

The default thread pool size for core.async is 8.

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

but what if you have 8 real threads and your thread pool is backed by all of them

doesn't it degenerate to the same thing?

And if you tie up that pool with blocking operations, pretty much all core.async operations are blocked.

you can't really tie up the whole pool can you?

i mean unless you block on every thread that backs it

i don't even see how you can block on even a single thread that backs it if you use go'

won't they just park?

blocking i/o won’t just park, unfort.

i'm sorry if i'm being combative i'm just trying to understand when and why to use thread vs go

Oh no worries! I’m just putting my thoughts together here 🙂

@bcbradley if it's asynchornous (non-blocking / event-driven / etc.) use go. If it blocks, use thread.

even that can be troublesome

if you are block on anything besides reading or writing to a channel, then don't use go

So java threads don’t map one-to-one to cpu threads, to start.

that is not true

they do

But you can have more java threads than cpu threads, can you not?

Not active all at once.

no

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.

by cpu threads you mean cores?

In order to program in this model, the user makes "callbacks" that fire when the cache changes in a specific way

for instance, if "val A" is cached --> fire this

sorry I meant os threads

I suppose I meant cores in this instance.

I guess that means what i'm doing is asynchronous right?

Why not make the whole stack async?

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).

or just burn a thread

yeah, that too, depends on your use case.

I mean, the jvm has threads, they work pretty well

also true. Most times people need async...they don't really

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

Is that right?

no

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.

Don't do IO inside a go block.

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

Alright that last bit helps me understand a lot @hiredman

So i should probably use threads not go blocks

since the cache could potentially block

Possibly...but I would consider if your cache needs to block or not.

it must block for write operations

if it is doing anything useful at all being there, it won't block most of the time for read operations

maybe threads for write and go blocks for read?

Well, what are you writing to? Many things these days support async IO

i'm making a clojure api for discord

i'm writing to a server somewhere far away

Right, and that's via HTTP?

yeah

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)

@tbaldridge > 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/

thanks! I'm sure, with this, i can get it going.

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...

@josh.freckleton I use Cursive via InteliJ, it uses nRepl, but it's not cider.