We never really supported Solaris, we pretended it implemented epoll,
but it never did see https://github.com/tokio-rs/mio/issues/1152. As no
one ever committed to being a maintainer for the port I'm removing it
now with this commit.
Instead replace it with illumuos on the CI, which we do support (as it
supports epoll) and for which we do have maintainers.
Adds one new function: unix::pipe, which is a wrapper around the pipe(2)
system call, and two new types: Sender and Receiver, wrappers around the
file descriptors.
This is a port of https://github.com/Thomasdezeeuw/mio-pipe, commit
8c3025edf128e90733e95327d88493887b93fcdd.
Both i386 and armv7s iOS targets are no longer supported by Rust (or
Apple for the matter), so remove them both from the CI.
And use the aarch64 (ARM 64 bit) iOS target instead.
## Motivation
Closes#1118
Mio should be as light as possible and forwards compatible to other non-blocking
I/O strategies such as user-land sockets.
Currently, depending on Mio means that all platform-specific networking
primitives and I/O source readiness polling functionality is present by default.
If a library is interested only in networking primitives but aims to provide an
other strategy for I/O source readiness polling, there is no way to disable the
provided implementation.
If a library is interested in the provided I/O source readiness polling
implementations, but only uses the TCP networking types, the UDP and UDS types
are also still provided.
This change proposes that Mio by default provides an API shim for its common
types such as `Poll`, `Events`, etc. Attempting to use them will result in a
panic. TCP, UDP, and UDS networking types are **not** present by default and
require feature flags to opt-in.
## Solution
### Overview
Below are the four feature flags that Mio now includes as opt-in features. By
default, no functionality is provided--only an API shim.
- `os-poll`: Provide the cross-platform implementations of `Poll`. This is
currently epoll, IOCP, or kqueue depending on the platform.
- `os-util`: Provide the cross-platform adapters for the platform's underlying
I/O source that implements `event::Source`. Currently, only Unix provides it's
`SourceFd` type. There are proposed solutions for a Windows equivalent being
worked on.
- `tcp`: Provide the TCP types and implementations
- `udp`: Provide the UDP types and implementations
- `uds`: Provide the UDS types and implementations. Currently, only Unix
provides types and implementations for this feature.
The above feature flags can be used in any combination. If a library opts in to
`os-poll` and `tcp`, then the `Poll` and TCP implementations will be provided.
Later, the library could provide it's own `Poll` implementation and opt-out of
`os-poll`. It could alternatively opt-in to UDP at a later point without issue.
### Details
Mio now has the following cfg macros: `cfg_os_poll`, `cfg_not_os_poll`,
`cfg_net`, `cfg_tcp`, `cfg_udp`, `cfg_uds`, `cfg_any_os_util` that conditionally
provide the related types and implementations. *(If any of these names are not
obvious about what they provide, please let me know!)*.
The macros--again similar to Tokio--conditionally provide shell types that
**panic upon use**, or hide/expose methods on types an API shim should not
provide (e.g. `Poll::new`).
## Tips for Review
This change touches a lot of files, but there are no intended functional or
behavioral changes. I would recommend first looking at what types are provided
by the root-level `lib.rs` or changes in the `mod.rs` files. *(If any of the
`mod.rs` files are not clear about what they conditionally expose, please let me
know!)*.
Next, I would look at the methods that are now conditionally provided on the
types. These are mostly confined to the OS specific `Poll` implementations, but
there are a few exceptions.
Finally, there are some further changes that reorganize `impl`s or move `use`
statements due to being conditionally used. Because this change is ultimately a
"refactor", I found myself moving some blocks of code around to group with
similar `impl`s and such. I'd like to keep those as part of this change (instead
of a separate PR), but please me know if have questions/concerns about any of
those.
Signed-off-by: Kevin Leimkuhler <kleimkuhler@icloud.com>
* Integrate lazycell 1.2.0 into the project
...rather than getting it from the crates.io. The problem is that latest
lazycell doesn't work with rust 1.18.0 anymore that mio supports. This
commit only adds the origincal lazycell.rs without any modifications.
I want commits to show the changes I made to the lazycell.rs 1.2.0.
* Fix lazycell to work with rust 1.18.0
* Removed example, which wouldn't compile, because lazycell wasn't detected.
* Simply use std instead of libcore.
* Removed associated constant, which is still an experimental feature in
rust 1.18.0.
* Fix android builds
* Delete doc examples for deprecated code
Thomas de Zeeuw