search

dpc / mioco.pre-0.9

Scalable, coroutine-based, asynchronous IO handling library for Rust programming language. (aka MIO COroutines).
Mozilla Public License 2.0
457 stars 30 forks source link

Growable slab. #8

Closed dpc closed 8 years ago

dpc commented 9 years ago

When running out of slab space, it would be better to just resize the slab instead of panicking or whatever mioco is doing now in such case. Also, maybe by using some cheap-lookup HashMap, we could eliminate the problem altogether. And by running on every-increasing tokens, we could eliminate potential spurious events caused by: https://github.com/carllerche/mio/issues/219 by just never reusing the same token (at least not until whole Token space wraps).

arthurprs commented 9 years ago

I believe http://doc.rust-lang.org/std/collections/struct.VecMap.html would fit in nicely. But we probably need something better than a linear-scan to find free slots.

dpc commented 9 years ago

Yes, the free slot scan... I was wondering if the vastness of the Token space couldn't be used to eliminate the problem in practice. Even a linear scan would be OK if the chance of hitting a occupied slot after Token integer wrapped was really small.

arthurprs commented 9 years ago

Yeah, indeed. Insertions may just increment the latest token. You can probably use the stdlib hashmap and the token itself as the hash.

3Hren commented 9 years ago

I vote for downgrading to HashMap by default (because it's growable) with predefined capacity, but also leave an ability for user to specialize allocator if required. Using policies for example.

dpc commented 8 years ago

I've implemented a growable slab in: https://github.com/carllerche/slab/pull/13, I'm closing this bug and switching to #67 for actual implementation. Should be easy fix.