mpmc_bounded_queue is not longer in Rust std public API about mio HOT 4 CLOSED

It would be nice if the Notify implementation were optional. I guess that most applications can use their own implementation of a message queue, and they only need the os::Awakener object.

from mio.

@vberger the easy fix would be to just vendor mpmc_bounded_queue.

@ayosec I don't follow. Why would it be nice if the notify implementation were optional? Is there overhead to having it? I assume you mean the generic? My guess is that the ergonomics of the API will go away with associated types & type defaults.

from mio.

I don't follow. Why would it be nice if the notify implementation were optional?

I think that the feature is really useful. My only concern is that the current implementation uses a fixed-size queue. If the server receives an unexpected peak, I guess that the new connections have to be dropped.

from mio.

Ah, yes, I plan to make the queue pluggable. However, IMO one should always use a bounded queue. When you use an unbounded queue, you are really just using a bounded queue w/ an unknown cap (hitting OOM) and not being able to sanely handle reaching those limits.

Creating a queue w/ 2MM entries would plausibly take less than 10MB RAM.

But anyway, like I said, I would like the queue to be pluggable eventually.

from mio.