| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2019-10-23 | Keep minimal available fd to accelerate fd allocation | DarcySail | |
| Use fd.next to store the iteration start position, which can be used to accelerate allocating new FDs. And adding the corresponding gtest benchmark to measure performance. @tanjianfeng COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gvisor/pull/758 from DarcySail:master 96685ec7886dfe1a64988406831d3bc002b438cc PiperOrigin-RevId: 276351250 | |||
| 2019-07-17 | Fix race in FDTable.GetFDs(). | Bhasker Hariharan | |
| PiperOrigin-RevId: 258635459 | |||
| 2019-07-02 | Remove map from fd_map, change to fd_table. | Adin Scannell | |
| This renames FDMap to FDTable and drops the kernel.FD type, which had an entire package to itself and didn't serve much use (it was freely cast between types, and served as more of an annoyance than providing any protection.) Based on BenchmarkFDLookupAndDecRef-12, we can expect 5-10 ns per lookup operation, and 10-15 ns per concurrent lookup operation of savings. This also fixes two tangential usage issues with the FDMap. Namely, non-atomic use of NewFDFrom and associated calls to Remove (that are both racy and fail to drop the reference on the underlying file.) PiperOrigin-RevId: 256285890 | |||
 |
index : gvisor | |
| Container Runtime Sandbox |
| summaryrefslogtreecommitdiffhomepage |