search

tokio-rs / mio

Metal I/O library for Rust.
MIT License
6.28k stars 722 forks source link

mpmc_bounded_queue is not longer in Rust std public API #62

Closed elinorbgr closed 9 years ago

elinorbgr commented 9 years ago

Following https://github.com/rust-lang/rust/pull/19274, mpmc_bounded_queue is no longer in the libstd public API of Rust.

Thus mio does no longer compile on last Rust and I don't see any immediate fix.

ayosec commented 9 years ago

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.

carllerche commented 9 years ago

@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.

ayosec commented 9 years ago

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.

carllerche commented 9 years ago

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.