Lets say you have websocket(or api), which return...

# coroutines

[rkeazor]

Lets say you have websocket(or api), which returns asynchronous response each time a request is made. However if more than one requests is sent the previous one will be canceled and the new one will be analyzed. In other words the most recent request is always the one analyzed. Assuming you have a stream of requests, using coroutines, how can you ensure all requests are processed.(Consider back pressure). Also the only way you know the request is completed or in the process, is via the response callback

[julian]

What do you mean by "... ensure all requests are processed..."? Because you say earlier that "...if more than one request is sent the previous one will be cancelled...".

[rkeazor]

So in other words, make sure all requests complete in. a sequential fashion . So in other words , if one request is made the coroutine should suspended and only continue when the callback is complete. I thinking a channel or a actor should be able to do this

[julian]

So the request currently in flight should or shouldn't be cancelled when a new request is available?

[rkeazor]

the requests should be queued while waiting for a response to happen

[darkmoon_uk]

Does this need to be any more exotic than some form of loop for your requests, which features a suspending call to process each request?

[rkeazor]

Well a request is made by key press and can happen at any time .so backpressure should also be considered

[asad.awadia]

@julian i feel you - the question and comments seem to contradict each other lol

[julian]

@rkeazor What do you want to do with the success or failure result? Do they need to be passed on to some other part of the application? When the request finally succeeds, should the entire mechanism terminate, or keep running?

[rkeazor]

Sorry guys it's sort of werid I guess. There is a fun requestSomething() . That once it is called it analyzes the request and once it is done it returns the result to a callback function response fun responseSomething(data)... Now let's say each time requestSomething() is called if there is a request currently being canceled and the new request will analyzed

[rkeazor]

Now the gotcha is this: let's say requestSomething() is called via a keyboard listener. Using cortines suspend and continuation mechanism, how can you ensure that all requests are processed regardless of how fast the person types is lol

[asad.awadia]

you keep contradicting yourself - you say if a new request comes on cancel the one being processed - then you say ALL requests should be processed regardless

[rkeazor]

@asad.awadia oh ok I see the confusion. so yea both are right , but wrong context. Currently the system cancels the old request when a new one comes in

[TwoClocks]

So the sending system queues requests & sends the requests and only allows "one in flight". If there are mutipul requests in the queue it can remove the duplicates before sending. something like that?

[TwoClocks]

So the sending logic needs to be in it's own thread/coroutine w/ a shared queue w/ whatever thread/coroutine is mkaing the requests.