Gotta admit, Win32's modern synchronization interfaces (introduced with Vista) are beautiful.

Once upon a time, POSIX specified that these static initializers could only be used for global variables, but apparently essentially all implementations have always supported these initializers for local variables as well, and POSIX recently enshrined this as a requirement.

I originally left this unimplemented because pthreads annoyingly doesn't support condvar on top of rwlocks. It turns out there's a trick that can be used involving an extra mutex and some redundant locking operations -- the same trick that powers std::condition_variable_any. I used that here.

Win32 support will come in a subsequent commit, before merging to master.

This is frequently needed. Sandstorm had `OwnCapnp` for this purpose:

https://github.com/sandstorm-io/sandstorm/blob/4d86a8144cdb43120ea12845738d0fe4a6ffcda1/src/sandstorm/util.h#L495-L525

The Workers codebase has some ad-hoc copies of this logic too, and multiple people have requested something similar on the mailing list.

This is a lot like Own<T>::attach() but for the case where you don't have a Own pointer, you just have a reference or value that you want to attach stuff to.

The main case where the code was wrong is when neither Content-Length nor Transfer-Encoding was provided on a response. In this case the response is delimited by closing the connection, but KJ previously rejected it outright. AFAICT almost no one on the whole internet relies on this anymore... almost.

Initializer lists are temporaries. The code apparently works in debug mode but fails when optimized.

Fix typos spotted by @a-robinson and update test failure messages to indicate that either testing failing could be due to OS SCM_RIGHTS truncation bug.

According to David Klempner, this turns out not to be a safe assumption:

https://twitter.com/CaptainSegfault/status/1112622245531144194

Interestingly, it turns out this optimization was also blocking the delivery of certain errors, because we would skip the read() where that error would otherwise be delivered. (Hence the unit test update.)

An endpoint (subclass of `Capability::Server`) may override `kj::Maybe<int> getFd()` to expose an underlying file descriptor.

A remote client may use `Capability::Client::getFd()` on the endpoint's capability to get that FD.

The client and server must explicitly opt into FD passing by passing a max-FDs-per-message limit to TwoPartyVatNetwork and using Unix sockets as the transport. Nothing other than that is needed.

Previously if the input stream being pumped from encountered an EOF while the other side of the pipe was being pumped elsewhere, we did not fulfill the tryPumpFrom() promise, leaving it hanging.

This is just the protocol change, not implementation.

Previously, FDs could only be sent separately from data, with the underlying implementation actually sending a dummy one-byte message.

For Cap'n Proto FD passing, it's better if we can attach the FDs to the RPC message they arrived with, because it avoids the need to pre-negotiate where FD passing is supported: if the sender sends FDs but the recipient doesn't arrange to receive them, the FDs will be discarded and closed automatically by the OS. Whereas, if we are sending separate one-byte messages, the recipient needs to know what to do with those.

This is redundant as the destructor already uses a recoverable assertion, which will not throw during unwind.

I have long assumed AutoCloseFd wrapped only an integer and was shocked to realize it was more that that...

Not sure how this slipped by for so long!

This class lets you hold a temporary value that is only safe to access under lock, while you release the lock to do some other work.