# Why the select I/O multiplexing model is considered broken by design

DevFeed: [Why the select I/O multiplexing model is considered broken by design](<https://devfeed.tech/articles/select-is-fundamentally-broken-38958.md>)

Original publisher: [Read original article](<https://idea.popcount.org/2017-01-06-select-is-fundamentally-broken>)

Author: Marek

Published: 2017-01-05T23:00:00Z

Content type: opinion

Language: en

Sources: [Marek Majkowski](<https://devfeed.tech/sources/marek-majkowski.md>)

Topics: [IO](<https://devfeed.tech/topics/io.md>), [TCP/IP](<https://devfeed.tech/topics/tcp-ip.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [Kernel](<https://devfeed.tech/topics/kernel.md>), [file](<https://devfeed.tech/topics/file.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [async](<https://devfeed.tech/tags/async.md>), [blog](<https://devfeed.tech/tags/blog.md>), [kernel](<https://devfeed.tech/tags/kernel.md>), [tcp-ip](<https://devfeed.tech/tags/tcp-ip.md>)

## AI overview

This article examines alternatives for I/O multiplexing and argues that the select model is broken by design because its semantics prevent effective kernel-side optimizations. It also discusses related technologies that inherit those semantics.

## Source excerpt

Select is fundamentally broken I/O multiplexing part #2 In a previous blog post we discussed a brief history of the syscall. The article concludes that some I/O multiplexing was necessary to do console emulation, games and non-trivial TCP/IP applications. The BSD designers chose the multiplexing model and other Unixes followed. But is the only multiplexing model? A good explanation can be found in the old revision of "The Design and Implementation of the FreeBSD Operating System" book.