tower-buffer probably doesn't need current_message slot

[carllerche]

Instead of having a current_message slot, perhaps the worker should "join" on the service and the request queue being ready.

Thoughts @jonhoo

[jonhoo]

I'm not entirely sure what that would look like?

[carllerche]

Ah, I meant to add more info, but forgot...

For context, I'm working on putting a PR together that removes DirectService.

But, roughly, this function would start with:

try_ready!(self.rx.poll_ready());
try_ready!(self.service.poll_ready());

Now I realize this would require additional APIs on mpsc::Receiver, but it should be possible!

[jonhoo]

Ah, I see what you mean. Yes, I think that could work, but only if you assume that a Service cannot become NotReady after it has reported Ready (I suppose the current code would also break if that were the case). I'm not sure why you need the self.rx.poll_ready though?

[carllerche]

You are correct. We do not need rx.poll_ready.

I believe it is a fair guarantee that once Service::poll_ready returns Ready, it must always return Ready until Service::call is called.

[jonhoo]

I was about to implement this, when I realized that this will also trigger the issue pointed out in #408/#412. If we poll_ready on the Service before we know we have a request to send it, then we may be "holding up" a slot in the service (such as in a Buffer) forever with no way of giving it back. So I think we should leave this as-is for the time being until a disarm mechanism is added.