Concurrency and Latency about req HOT 5 CLOSED

Thanks! No those will run sequentially, just like with http-client. You'd need to use something like async to make them run in parallel. For latency you could perhaps use clock to measure how long the entire req business takes, Chris Done has a blog post about this:

http://chrisdone.com/posts/measuring-duration-in-haskell

If you only want to measure time from start of request up to when you get a response you probably could register "end time" in reqBr before you stream the response.

from req.

It seems like meshing with async seems to force everthing into IO. Essentially resulting in

runConcurrently $ (,) <$> Concurrently (runReq def (req GET ...))
                      <*> Concurrently (runReq def (req GET ...))

this seems a bit less elegant than I'd like it to be.

Thanks for the point towards Chris Dones post. I'll look into it!

from req.

There is also lifted-async, although I'd not recommend using it over stateful monadic stacks as a general practice.

from req.

Ohh right. Completely forgot about lifted-async. I'm an idiot, sorry! And yes, state and concurrency almost never play well together :-)

As is, I guess my only request is that the sequential nature of the requests is noted in the documentation, explicitly mentioning that they are not concurrent (to ensure the keyword
is easily found).

Thanks again!

from req.

I don't know how they possibly can be concurrent, because they return the (actual) response in a monadic context. That means that I can write:

main = do
  response <- req GET ...
  if response ....
    then req GET ...foo
    else req GET ...bar

Now if there were a possibility of concurrency, I would not be able to write code like this. Just like you cannot write this sort of code with async because the concurrent framework only provides you the power of applicative (concurrency-friendly concept), not monad (imposes sequential execution).

from req.