So what is flowable then for? specifying other behavior than buffering?

Flowable is for applying backpressure up the entire operator chain when the producer is faster than the consumer

so Observable.flatMap is special case?

tldr; I want a Downloader which limits N downloads in parallel, should I rely on this flatmap buffer or explicitly flowable?

not really. lots of operators buffer. the most notable is probably observeOn

unless it's expensive to produce the list of things which need downloaded, there's no reason to use backpressure to limit the input

I see thanks.

Btw, I see people using a custom executor scheduler with N threads for this

using io() and limiting via that param is preferrable right?

yes, it will reuse the same threads that are being used for all other IO work in the same process but only actually limit those which are flowing through this particular stream

yea exactly

btw is there an way to touch and modify that buffer? priority sort it, remove stuff, etc?

Or rather, is there a way to impose that limit on io() scheduler other than flatmaping? what if I have just a straight observable

Observable.fromCallable { downloadFile() }
  .subscribeOn(<http://Schedulers.io|Schedulers.io>())
  .subscribe { .. }

no. are you asking for something like

<http://Schedulers.io|Schedulers.io>().limit(5)

?

yea

there is nothing provided out-of-the-box for that, but you could write that yourself by creating a Scheduler which wraps

io()

and then limits worker creation to 5. You would have to decide how to distribute the work that's buffered yourself. Probably with a single queue giving you the ability to do things like sort by priority. But we're not far off from the "just use executors" case.

yes i'll think about it, thanks

for you help

Btw I'm looking at ThreadPoolExecutor, its already has the param of BlockingQueue<Runnable> workQueue, this would be easily swapped by some priority queue

and from what I understand even fixed thread pool kills idle threads, so maybe its not so bad to not use IO scheduler?

-- Is there any benefit to having Retrofit Rxjava adapter

RxJava2CallAdapterFactory.createAsync()

over

RxJava2CallAdapterFactory.create()

Obviously I read that second one applies no schedulers, and first I runs on OkHttp threads

So, other than not having to apply scheduler, is there any benefit in having requests run on okhttp threads?

Assuming no other part of the app uses call.enqueue, is there any perf benefit?

if you're doing http/2 you'll likely want OkHttp to manage the threads since all the bookkeeping and request/response setup is done on a single thread

individual threads are only used when a response body is handed to the application layer

so the first part is on okhttp thread regardless of scheduler?

or is it only for enqueue's

I don't remember

np, so I take it if im not doing http2 it doesnt matter?

althought now that I think about it I have okhttp backing Glide