Motivation:
EventLoopPromise.succeed/fail has extraneous labels that don't add
anything but noise.
Modifications:
remove extraneous labels
Result:
less noise in the code
BUGFIX: BlockingIOThreadPool not releasing the latest WorkItem
Fix is to clear the latest work item just before waiting for
the next one to be submitted.
Added two tests to validate the fix: submitting only one work item
to an IO thread pool, and submitting two consecutive work items.
Thanks to Gwynne Raskind for help troubleshooting & fix
(cherry picked from commit 8df414b716)
Motivation:
Swift naming guidelines mandate that factory methods start with `make`,
like `makeSomething`. We had a few that were `newSomething`.
Modifications:
make all factories start with make
Result:
more compliant to Swift naming rules
Motivation:
making a promise of a type is more grammatical than making a promise for
a type.
Modifications:
s/newPromise(for/newPromise(of/g
Result:
more grammar
Motivation:
When creating new promises I always find it very frustrating to type the
`: EventLoopPromise<Type>` type annotation but it's necessary for the
compiler to know type the promise will be fulfilled with.
Modifications:
allow an optional `for: SomeType.self` parameter for `newPromise` as
let p = eventLoop.newPromise(for: Int.self)
is much easier to type than
let p: EventLoopPromise<Int> = eventLoop.newPromise()
Result:
easier to write code
Motivation:
Swift 5 complains on redundant modifiers. For example declaring a
`public func` inside of a `public extension` is now a warning. I don't
agree with this but I dislike warnings even more, so...
Modifications:
remove all redundant modifiers that the compiler now warns about such as
swift-nio/Sources/NIOPriorityQueue/PriorityQueue.swift:90:5: warning: 'public' modifier is redundant for property declared in a public extension
Result:
no warnings in Swift 5
Motivation:
Not shutting down IOThreadPools leads to thread leaks so we should
verify they're actually shut down.
Modifications:
add a check that we're shutting down
Result:
fewer thread leaks
Motivation:
BlockingIOThreadPool used to call out with a lock held and on top of
that on the wrong thread...
Modifications:
Make BlockingIOThreadPool call out on the supplied `queue`
Result:
fewer deadlock and surprises
Motivation:
The BlockingIOThreadPool were very sparse which is improved here.
Modifications:
The existing docs didn't really help much if you didn't already know why
you'd need an extra thread pool for blocking work.
Result:
docs more clear on when to use BlockingIOThreadPool
Motivation:
Opening a file, seeking it or querying its size (or other information)
is blocking on UNIX so `NonBlockingFileIO` should support that too.
Modifications:
Added a method to `NonBlockingFileIO` which lets the user open a file
without blocking the calling thread.
Result:
Less blocking is good :)
Motivation:
Sometimes we deviated from the style the Swift stdlib sets out for no
reason.
Modifications:
Fixed some stylistic deviations.
Result:
Looks more Swift-like.
* Expose BlockingIOThreadPool
Motivation:
Sometimes we need to execute some blocking IO. For this we should expose the BlockingIOThreadPool that can be used.
Modifications:
- Factor out BlockingIOThreadPool
- Added tests
- Correctly start threadpool before execute NonBlockingIO tests.
Result:
Possible to do blocking IO.
* Corrys comment
* Correctly start pool before using it
Johannes Weiss