core-async 2025-03-05

Maybe it’s just me, but this is the 2nd time I got burned thinking flow/inject respects order. Could we add a N.B.: inject does not guarantee order. Use ::flow/in-ports and a channel for that ?

All messages sent in a single inject call are made in order (it’s a doseq of >!!). No set of unawaited independent inject calls to different target coords could ever be in an order since each proc is always async relative to the others. But since inject returns a future you can ensure order by waiting for it before proceeding. Not sure how much more control you could want.

❤️ 1

P.S. I know the inject function specifically states “asynchronously”, but I still fell for the mental trap

Alex Miller (Clojure team) 2025-03-05T13:27:21.432129Z

Order of what? I don’t understand

I guess he means if you do :

(do
  (flow/inject graph [:pid :nums-in] 1)
  (flow/inject graph [:pid :nums-in] 2)
  (flow/inject graph [:pid :nums-in] 3))
there is no guarantee that they will be received by :pid transform in that order

Which makes sense from the doc string saying Asynchronously but I guess people can misuse inject with code like (doseq [m msgs] (flow/inject ... m)) to push a bunch of messages into a graph and be confused with the result

Yes. This is exactly what I mean. Sorry if it wasn't clear

So even injections to the same [pid in-id] may be processed out of order?

Yes. Each injection is put on a thread pool to be executed

Alex Miller (Clojure team) 2025-03-05T19:41:29.193199Z

I don’t know, that’s what “asynchronously” means?

maybe adding to the doc string a warning like "Since inject is async it shouldn't be used to inject a sequence of messages if their order matters, use flow/in-ports instead"?

Maybe it's just me, but wouldn't flow/infect be an invaluable edition to any API? I don't really care what it does -- maybe make a server explode somewhere?