1
0
mirror of https://github.com/golang/go synced 2024-11-23 04:50:06 -07:00
go/api
Sven Anderson 251daf46fb runtime: implement Pinner API for object pinning
Some C APIs require the use or structures that contain pointers to
buffers (iovec, io_uring, ...).  The pointer passing rules would
require that these buffers are allocated in C memory and to process
this data with Go libraries it would need to be copied.

In order to provide a zero-copy way to use these C APIs, this CL
implements a Pinner API that allows to pin Go objects, which
guarantees that the garbage collector does not move these objects
while pinned.  This allows to relax the pointer passing rules so that
pinned pointers can be stored in C allocated memory or can be
contained in Go memory that is passed to C functions.

The Pin() method accepts pointers to objects of any type and
unsafe.Pointer.  Slices and arrays can be pinned by calling Pin()
with the pointer to the first element.  Pinning of maps is not
supported.

If the GC collects unreachable Pinner holding pinned objects it
panics.  If Pin() is called with the other non-pointer types it
panics as well.

Performance considerations: This change has no impact on execution
time on existing code, because checks are only done in code paths,
that would panic otherwise.  The memory footprint on existing code is
one pointer per memory span.

Fixes: #46787

Signed-off-by: Sven Anderson <sven@anderson.de>
Change-Id: I110031fe789b92277ae45a9455624687bd1c54f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/367296
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
2023-05-19 14:59:14 +00:00
..
next runtime: implement Pinner API for object pinning 2023-05-19 14:59:14 +00:00
except.txt cmd/api: add API checks for freebsd/arm64 2023-02-17 20:31:46 +00:00
go1.1.txt strconv: quote rune 007F as \x7f, not \u007f 2022-03-31 20:37:15 +00:00
go1.2.txt
go1.3.txt
go1.4.txt
go1.5.txt
go1.6.txt
go1.7.txt
go1.8.txt
go1.9.txt cmd/api: set architecture sizes when type checking 2021-10-04 20:20:20 +00:00
go1.10.txt
go1.11.txt
go1.12.txt
go1.13.txt
go1.14.txt cmd/api: add API checks for freebsd/arm64 2023-02-17 20:31:46 +00:00
go1.15.txt
go1.16.txt cmd/api: track darwin arm64 port 2022-12-02 16:30:41 +00:00
go1.17.txt cmd/api: add API checks for freebsd/arm64 2023-02-17 20:31:46 +00:00
go1.18.txt cmd/api: add API checks for freebsd/arm64 2023-02-17 20:31:46 +00:00
go1.19.txt cmd/api: track deprecations 2022-12-02 16:29:41 +00:00
go1.20.txt cmd/api: add API checks for freebsd/riscv64 2023-02-17 21:23:32 +00:00
go1.txt
README cmd/api: require proposal # for new API features 2022-03-14 21:43:16 +00:00

Files in this directory are data for Go's API checker ("go tool api", in src/cmd/api).

Each file is a list of API features, one per line.

go1.txt (and similarly named files) are frozen once a version has been
shipped. Each file adds new lines but does not remove any.

except.txt lists features that may disappear without breaking true
compatibility.

Starting with go1.19.txt, each API feature line must end in "#nnnnn"
giving the GitHub issue number of the proposal issue that accepted
the new API. This helps with our end-of-cycle audit of new APIs.
The same requirement applies to next/* (described below), which will
become a go1.XX.txt for XX >= 19.

The next/ directory contains the only files intended to be mutated.
Each file in that directory contains a list of features that may be added
to the next release of Go. The files in this directory only affect the
warning output from the go api tool. Each file should be named
nnnnn.txt, after the issue number for the accepted proposal.
(The #nnnnn suffix must also appear at the end of each line in the file;
that will be preserved when next/*.txt is concatenated into go1.XX.txt.)