Motivation:
We do not need to use return in the closures used in the examples.
Modifications:
- Remove return
- Remove bug where we set the same channel option two times in one example
Result:
Cleaner code.
Motivation:
After the previous change to the channel writes, the datagram and the
stream PWMs behaved differently and there was code duplication.
Modifications:
Removed different behaviour & reduced code duplication
Result:
Less code and hopefully less bugs.
Motivation:
Channel writes are a complex matter and it was even more
complex when `FileRegion` and `ByteBuffer` were completely
different kinds of objects. Now that they're more in line we can
simplify a lot of things.
Modifications:
Rewrote the inner layers of channel writes to make them more readable
and hopefully more correct.
Result:
hopefully fewer bugs.
Motivation:
We should allow to use a custom Resolver for the ClientBootstrap as users may want to use different strategies then using a DNS based approach.
Beside this GetaddrinfoResolver should not keep any state and should be more rebust as at the moment it only will ever complee the future for the A query if also an AAAA query was sent.
Modifications:
- Make Resolver protocol public
- Remove state in GetaddrinfoResolver and so allow to use it multiple times. Now it is also more conform to the protocol itself.
Result:
Allow to use custom Resolver
Motivation:
The bootstraps are important objects that everybody will use and I think
the best way to explain them is a simple example.
Modifications:
Added examples in the doc comments.
Result:
hopefully easier to use.
Motivation:
Previously `FileRegion` was a special snow flake, a bit like
`ByteBuffer` but also totally different. That caused surprise and made
`PendingWritesManager` even harder. It was also used to manage the
lifetime of a file descriptor but only sort of.
Modifications:
We now have a `FileHandle` which is a one-to-one mapping with a file
descriptor and its lifetime must be managed appropriately.
Result:
hopefully less bugs and fd leaks.
* Add a chat server / client example
Motivation:
We should add some more complex examples.
Modifications:
Add a chat server and client example.
Result:
More examples.
* Comments
* More comments
Motivation:
Lots of our most important operations had redundant labels like
func write(data: NIOAny)
the `data: ` label doesn't add anything meaningful and therefore it
should be removed.
Modifications:
removed lots of redundant labels
Result:
less redundant labels
Motivation:
The code to filter out ChannelError.eof when reading from the socket and not call fireErrorCaught(...) was broken and so the error was propagated through the pipeline.
Modifications:
- Correctly filter out .eof
- Added testcase
Result:
Correct handling of .eof
Motiviation:
We already include an echo server as example but not a client portion. This example sends a message to the server and once it received back the message it will close the connection and exit.
Modification:
Add NIOEchoClient example.
Result:
More examples.
Motivation:
In ClientBootstrap we use Int to represent the port but in ServerBootstrap we use Int32. As swift usually always use Int we should just use Int everywhere to represent the port.
Modifications:
Change Int32 to Int for port
Result:
More consistent API
Motivation:
We should better allow access to pthread_t via an withUnsafe function which is more swift-like.
Modifications:
- Add withUnsafePthread and use it
- mark pthread_t as private in Thread.
Result:
More swifty code.
Motivation:
We sometimes used fatalError(...) where we really could just use precondation(...). Beside this we can also consolidate the #if #else code for handling Darwin and Linux differently and so make the code easier to maintain.
Modifications:
- Use precondation
- Consoldate #if #else blocks for Thread
Result:
Cleaner and easier to maintain code.
* Use aliases to reduce duplication and make it easier to maintain.
Motivation:
We used many #if #else blocks which made the code very clumby.
Modifications:
Use aliases and define these in one place.
Result:
Easier to maintain code.
* Comments
* Comments
- This fixes Bootstrap's ChannelOptionStore.applyAll to return a future rather
than synchronously iterating through all the options.
- This is particular important because when a server accepts a child, if the
child channel is on a different event loop then it is possible the
synchronous calls may deadlock (if the child's eventloop happens to be
scheduled with a similar accept sequence).
- I did not tackle also making getOption() async, which means the Channel API
is asymmetric at the moment. That should probably be addressed, potentialy
with synchronous wrappers for API compatibility.
- Fixes: <rdar://problem/37191923> [Omega] Worker tasks fail to close subtasks (many connections in CLOSE_WAIT state)
Cory Benfield