# Restoring Channel#full? **URL:** https://forum.crystal-lang.org/t/restoring-channel-full/1148 **Category:** Crystal Contrib **Created:** [September 23, 2019, 8:17pm UTC](https://forum.crystal-lang.org/t/restoring-channel-full/1148 "2019-09-23T20:17:17Z") **Posts on this page:** 1 **Showing post:** 11
### Author: ![bcardiff](https://yyz2.discourse-cdn.com/flex036/user_avatar/forum.crystal-lang.org/bcardiff/32/3_2.png) [@bcardiff](https://forum.crystal-lang.org/u/bcardiff) #### Post date: [September 24, 2019, 1:22pm UTC](https://forum.crystal-lang.org/t/restoring-channel-full/1148/11 "2019-09-24T13:22:26Z")
The removal of `Channel#full?` and `#empty?` was intentional. They leaked state of the channel in a way that can’t be guarantee. The sender of a buffered channel should not need to be aware whether the `send` will block or not (same way for the receiver). If there is a need to limit quota then I suggest splitting the task and using some fibers for that only. At the end of the day there is already a fiber to accept each request. I don’t expect to be much different. @jgaskins regarding the connection pool logic exposed, the creation of them are serialized. That is an unneeded penalty you are exposing to simultaneous clients. In crystal-db that is addressed by unlocking during the creation of the connection but counting the number of connection been created. --- _[View the full topic](https://forum.crystal-lang.org/t/restoring-channel-full/1148)._