| commit | bcc6f70f8d4d666f3a6c2273d5a611b750dbb82a | [log] [tgz] |
|---|---|---|
| author | James Tucker <raggi@google.com> | Wed Dec 05 17:40:45 2018 -0800 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Sat Dec 08 02:39:53 2018 +0000 |
| tree | 60cba9c70a4c95b277969f050d2a87fe3b256b80 | |
| parent | 9c9f7df9a846936365b682ada16da5c7c0133ae6 [diff] |
[fdio] do not accept sockets with a full fd table If the fd table is full, pulling sockets from the control channel results in consuming the incoming connection, but being unable to actually service it - we then immediately close (which then ends up in linger). Other processes would then not be able to pull these sockets (in a load balance scenario), and netstack also potentially loses the ability to apply policy from having a full listen queue. Instead, try to allocate an fd up front, and only if found accept the socket from the control channel. This is more conformant with common accept behaviors. Test: install a package with 5500 blobs with a package server routed via a remote port forward over ssh. Observe successful install rather than failure. Bug: PKG-371 #comment fdio: do not accept sockets with a full fd table Change-Id: Idb5513ada590b0d8da2f5cd68b4d734765e438d4
Zircon is the core platform that powers the Fuchsia OS. Zircon is composed of a microkernel (source in kernel/...) as well as a small set of userspace services, drivers, and libraries (source in system/...) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation.
The canonical Zircon Git repository is located at: https://fuchsia.googlesource.com/zircon
A read-only mirror of the code is present at: https://github.com/fuchsia-mirror/zircon
The Zircon Kernel provides syscalls to manage processes, threads, virtual memory, inter-process communication, waiting on object state changes, and locking (via futexes).
Currently there are some temporary syscalls that have been used for early bringup work, which will be going away in the future as the long term syscall API/ABI surface is finalized. The expectation is that there will be about 100 syscalls.
Zircon syscalls are generally non-blocking. The wait_one, wait_many port_wait and thread sleep being the notable exceptions.
This page is a non-comprehensive index of the zircon documentation.