Long polling

[jeromegn]

Would it be possible for the poll future to stay pending until there's actual data to read? I thought that would be the default behaviour and it surprised me when calls to poll returned an empty set of messages when there were messages (just none visible at the time).

Given how libqueued works, I'm not sure if that's possible without using file locks or something like that.

[wilsonzlin]

Yes that's a great idea, and how some other queue services work (i.e. SQS). I don't believe this would be too difficult:

• For libqueued, a simple VecDeque of SignalFutureControllers would work; every second a background task in libqueued could check if there's any available messages and pop them to the list of pending futures in order.
• For queued, the endpoint handler should simply await the signal. So long as the client doesn't decide to disconnect, the response can technically take forever. Standard HTTP should work (no need for something like WebSockets).
• Two things to handle would be detecting HTTP client disconnection, and cancelling the SignalFutureController.

I may take a look into this once I get time. Also happy to accept any PRs.

[jeromegn]

That makes sense. I'm interested the most in libqueued, there's a big chance I'll write my own HTTP server instead of using queued.

• For libqueued, a simple VecDeque of SignalFutureControllers would work; every second a background task in libqueued could check if there's any available messages and pop them to the list of pending futures in order.

If nothing is polling, that VecDeque could grow unbounded, additional logic would be required so that doesn't happen. Possibly a way to fallback to long polling if there's no messages?