Commit Graph

10 Commits

Author SHA1 Message Date
David Nadoba 6720612111
Drop Swift 5.5 (#2406)
* Drop Swift 5.5

* Use `swift-atomics` 1.1.0 with `Sendable` adoption
2023-04-17 08:40:35 +01:00
David Nadoba fbe7ef484a
Adopt `Sendable` for Types in `NIOWebSocket` (#2217) 2022-07-05 11:50:55 +01:00
Cory Benfield 64285cbff2
Clean up dependencies and imports. (#1935)
Motivation:

As we've largely completed our move to split out our core abstractions,
we now have an opportunity to clean up our dependencies and imports. We
should arrange for everything to only import NIO if it actually needs
it, and to correctly express dependencies on NIOCore and NIOEmbedded
where they exist.

We aren't yet splitting out tests that only test functionality in
NIOCore, that will follow in a separate patch.

Modifications:

- Fixed up imports
- Made sure our protocols only require NIOCore.

Result:

Better expression of dependencies.

Co-authored-by: George Barnett <gbarnett@apple.com>
2021-08-12 13:49:46 +01:00
Cory Benfield b053967abd Support writing WS header to user buffer. (#1168)
Motivation:

In some cases it may be possible to write the (usually small) web socket
frame header to the buffer provided by the user. If we do this we can
avoid an extra pipeline traversal for the small write. This is only
going to be a performance win in cases where we can avoid a
copy-on-write operation on the buffer, but if we can then it's a useful
small win to achieve.

Modifications:

- Refactored the WebSocketFrameEncoder to potentially prepend the frame
    header.
- Added a missing @inlinable attribute.
- Tests.

Result:

Potentially improved performance.
2019-11-27 18:52:03 +00:00
Cory Benfield a796af1a96
Reduce allocations in WebSocketFrameEncoder. (#1161)
Motivation:

The WebSocketFrameEncoder naively allocated a new block to write the
frame header into every time it wrote. This is excessive: in many cases
it would be able to re-use the same buffer as last time.

Modifications:

- Attempt to re-use the buffer we used for the last header.

Result:

Fewer allocations in some applications.
2019-10-15 15:45:26 -07:00
Johannes Weiss a41280919e
rename ctx to context (#842)
Motivation:

`ctx` was always an abbreviation was 'context` and in Swift we don't
really use abbreviations, so let's fix it.

Modifications:

- rename all instances of `ctx` to `context`

Result:

- fixes #483
2019-02-25 18:20:22 +00:00
Johannes Weiss 1198931823 ByteBuffer: rename set(<type>:, ...) to set<Type>(...) (#812)
Motivation:

ByteBuffer methods like `set(string:)` never felt very Swift-like and
also didn't look the same as their counterparts like `getString(...)`.

Modifications:

- rename all `ByteBuffer.set/write(<type>:,...)` methods to
  `ByteBuffer.set/write<Type>(...)`
- polyfill the old spellings in `_NIO1APIShims`

Result:

code more Swift-like
2019-02-12 11:11:45 +00:00
Johannes Weiss aaf434022f
fix limits on 32-bit systems to values that work (#580)
Motivation:

We should have different constants for 32-bit systems where necessary
for example all the maximums should be Int32.max and not UInt32.max
because UInt32.max doesn't fit into an Int on 32-bit platforms. But
where unnecessary 32-bit and 64-bit should share maximum values.

Modifications:

- removed some constraints that should be unnecessary
- skip tests that can't work on 32-bit systems

Result:

better and more consistent 32-bit runs
2018-08-23 10:38:47 +01:00
Helge Heß e8c04e0eca Make tests work on 32-bit (#486)
* 32-bit fix for tests: Replace 0xDEADBEEF w/ 0x1337BEEF

Motivation:

Make tests compile on Raspberry Pi.

Modifications:

- Change tests so that they compile on 32-bit machines,
like Raspi. Replaced 0xDEADBEEF which doesn't fit into
an Int32, w/ 0x1337BEEF.
- make ByteBuffer work better on 32-bit
- fix other wrong assertions and limits that are too big on 32bit

Also use TimeAmount.Value in one test.

Result:

Tests will compile on Raspi ...
2018-08-16 18:05:11 +01:00
Cory Benfield b542775605 Add initial websocket codec. (#109)
Motivation:

Websockets is a major protocol in use on the web today, and is
particularly valuable in applications that use asynchronous I/O
as it allows servers to keep connections open for long periods of
time for fully-duplex communication.

Users of NIO should be able to build websocket clients and servers
without too much difficulty.

Modifications:

Provided a WebsocketFrameEncoder and Decoder that can serialize and
deserialize Websocket frames.

Result:

Easier use of websockets.
2018-03-13 17:24:54 +01:00