- 11 Nov, 2019 2 commits
-
-
Kenton Varda authored
tls-test: Update error message to match new boringssl behavior
-
Joe Lee authored
Introduced in 58d56f4c5 ("Enable TLS 1.3 by default").
-
- 08 Nov, 2019 1 commit
-
-
Kenton Varda authored
Add getsockname() to ConnectionReceiver.
-
- 07 Nov, 2019 1 commit
-
-
Kenton Varda authored
This is a no-brainer given AsyncIoStream has getsockopt() and getsockname(), whereas ConnectionReceiver has only getsockopt().
-
- 01 Nov, 2019 1 commit
-
-
Kenton Varda authored
Make HttpClient adapter preserve exception behavior
-
- 31 Oct, 2019 1 commit
-
-
Joe Lee authored
Ideally, the HttpClient/HttpServer adapters should maintain the invariant that the behavior of a given client is the same as the behavior of newHttpClient(newHttpService(client)). Prior to this change, the HttpClient wrapper lazily called request(), so a client whose request() eagerly threw an exception could produce a different exception when called directly versus when wrapped -- the laziness allowed additional code to run. This was particularly evident when making a request with a body, since code using a wrapped client would be able to set up a subsequent BlockedWrite, eventually resulting in a "read end of pipe was aborted" exception instead of the actual exception. This change makes HttpClientAdapter::request() execute the wrapped request() eagerly. (Note that it partially undoes 90d48343... Hopefully, it preserves the desired behavior added there.)
-
- 28 Oct, 2019 4 commits
-
-
Kenton Varda authored
Detect and report when a HashMap suffers from excessive collisions.
-
Kenton Varda authored
Fix failures in http-over-capnp-test.
-
Kenton Varda authored
`task` needs to be the last member of ServerRequestContextImpl, because when we construct it, we call `service.request()`, which may call back to send() or acceptWebSocket(), which require `replyTask` to be initialized.
-
Kenton Varda authored
And fix a bug detected by this.
-
- 23 Oct, 2019 1 commit
-
-
Kenton Varda authored
Various bug fixes
-
- 22 Oct, 2019 4 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
The RPC system itself can sometimes call `releaseParams()` redundantly after the application has already called it. So, it's important that it be idempotent.
-
Kenton Varda authored
-
Kenton Varda authored
-
- 15 Oct, 2019 2 commits
-
-
Kenton Varda authored
Add std-iterator.h to build files
-
Vitali Lovich authored
-
- 14 Oct, 2019 4 commits
-
-
Kenton Varda authored
Suppress MSVC warnings in headers files
-
Kenton Varda authored
Add compat/std-iterator.h
-
Vitali Lovich authored
Allow including a header to obtain the iterator traits instead of needing to carefully define a slightly more obscure macro that someone might be tempted to define globally.
-
Vitali Lovich authored
For Visual Studio we have to wrap the headers with push/pop pragmas at the top and bottom of the file. Define common macros for suppress/unsuppress KJ & the appropriate macros for CAPNP begin/end header wrappers. Because there's a chicken egg problem the KJ_BEGIN_HEADER/CAPNP_BEGIN_HEADER macros are placed below all includes to ensure that the appropriate common.h file has been sourced.
-
- 04 Oct, 2019 2 commits
-
-
Kenton Varda authored
Fixes #889.
-
Kenton Varda authored
-
- 03 Oct, 2019 2 commits
-
-
Kenton Varda authored
Fix handling of queued RT signals, plus some other crap
-
Kenton Varda authored
-
- 02 Oct, 2019 4 commits
-
-
Kenton Varda authored
For regular (non-RT) POSIX signals, the process can only have at most one instance of each signal queued for delivery at a time. If another copy of the signal arrives before the first is delivered, the new signal is ignored. The idea was that signals are only meant to wake the process up to check some input; the signal itself is not the input. POSIX RT signals are different. Multiple copies of the same signal can be queued, and each is delivered separately. Each signal may contain some additional information that needs to be processed. The signals themselves are input. UnixEventPort's `onSignal()` method returns a Promise that resolves the next time the signal is delivered. When the Promise is resolved, the signal is also supposed to be blocked until `onSignal()` can be called again, so that the app cannot miss signals delivered in between. However, the epoll/signalfd implementation had a bug where it would pull _all_ queued signals off the `signalfd` at once, only delivering the first instance of each signal number and dropping subsequent instances on the floor. That's fine for regular signals, but not RT signals. This change fixes the bug and adds a test. Incidentally, the poll()-based implementation has been correct all along.
-
Kenton Varda authored
I don't really know how to test this since the other cmsg types are bizarre and non-portable, but they do exist.
-
Kenton Varda authored
This and many other characters are surprisingly allowed by the relevant RFCs. But it turns out we implemented the RFCs correctly, so yay.
-
Kenton Varda authored
-
- 30 Sep, 2019 1 commit
-
-
Edward Z. Yang authored
I initially didn't read the docs carefully enough and returned a StringPtr to a locally allocated string. Whoops. Make the doc a little clearer about this.
-
- 19 Sep, 2019 1 commit
-
-
Kenton Varda authored
Increase arenaSpace for emscripten builds
-
- 17 Sep, 2019 1 commit
-
-
Timothy Trindle authored
-
- 16 Sep, 2019 2 commits
-
-
Kenton Varda authored
kj::atomicAddRef(): Fix assertion error message
-
Joe Lee authored
-
- 11 Sep, 2019 6 commits
-
-
Kenton Varda authored
Define and implement HTTP-over-Cap'n-Proto
-
Kenton Varda authored
It seems like MSVC is generating this function in translation units where it isn't acutally called, which inadvertently causes non-RPC Cap'n Proto code to depend on kj-async.
-
Kenton Varda authored
-
Kenton Varda authored
The documentation for this method clearly says that sending the message cannot be delayed because ordering may matter. Only resolving of the returned promise can be delayed to implement flow control.
-
Kenton Varda authored
-
Kenton Varda authored
Rationale: If this were a native OS pipe, closing or aborting one end would cause the other end to throw DISCONNECTED. Note that dropping the read end of a userland pipe is implemented in terms of aborting it, which makes it even more clear that this is a disconnect scenario.
-