| commit | 342d34b17a40358ef5024d68cf0060258e68059d | [log] [tgz] |
|---|---|---|
| author | James Tucker <raggi@google.com> | Mon Dec 10 14:39:07 2018 -0800 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Dec 11 22:41:31 2018 +0000 |
| tree | 5d57a34a041e58ea5a6723da74f72919dad4a463 | |
| parent | e6c5973eaab5e5531c7e3b872be0da64d593a61c [diff] |
[fdio] only accept sockets when there's a free fd This change introduces a reservation mechanism throughout fdio that can be used in the intermediate time between a callers request for a new fd, and when that request is fulfilled by some remote. This reservation mechanism is then used in the socket accept path to prevent client programs from pulling sockets from the listen queue if they do not have an fd with which they can service the socket. A prior change was reverted in bbdb4a51d5849d91c73945994be75db397528dd5 which instead attempted to simply hold the fdtab mutex for the duration. That approach was flawed because it creates a deadlock in the (common) socket scenario of: - listen - thread(connect) - accept If the accept call races connect. This approach likely should also be used in open and connect among other places to avoid creating new remote resources that can not be serviced. Test: garnet package: netstack_tests Bug: PKG-371 #comment accept does not pull sockets it can't service Change-Id: Ic7745bca80c6cec3bad468bfc1d923a275e4159b
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.