qbit/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-09-29 05:14:29 -06:00
Code Releases Activity

plugin: add warning

Browse Source 
The plugin mechanism has a number of serious drawbacks.
This change documents them.

Fixes #56893

Change-Id: I1309ac8520f7471dd9ace5be28a8dc3339fdf2db
Reviewed-on: https://go-review.googlesource.com/c/go/+/452695
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
This commit is contained in:
Alan Donovan 2022-11-21 22:33:43 -05:00 committed by Gopher Robot
parent 72fdecafc0
commit ee56b3c510
1 changed files with 50 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
src/plugin/plugin.go
View File

@ -13,8 +13,56 @@
// already part of the program are called. The main function is not run.
// A plugin is only initialized once, and cannot be closed.
//
// Currently plugins are only supported on Linux, FreeBSD, and macOS.
// Please report any issues.
// # Warnings
//
// The ability to dynamically load parts of an application during
// execution, perhaps based on user-defined configuration, may be a
// useful building block in some designs. In particular, because
// applications and dynamically loaded functions can share data
// structures directly, plugins may enable very high-performance
// integration of separate parts.
//
// However, the plugin mechanism has many significant drawbacks that
// should be considered carefully during the design. For example:
//
// - Plugins are currently supported only on Linux, FreeBSD, and
// macOS, making them unsuitable for applications intended to be
// portable.
//
// - Applications that use plugins may require careful configuration
// to ensure that the various parts of the program be made available
// in the correct location in the file system (or container image).
// By contrast, deploying an application consisting of a single static
// executable is straightforward.
//
// - Reasoning about program initialization is more difficult when
// some packages may not be initialized until long after the
// application has started running.
//
// - Bugs in applications that load plugins could be exploited by an
// an attacker to load dangerous or untrusted libraries.
//
// - Runtime crashes are likely to occur unless all parts of the
// program (the application and all its plugins) are compiled
// using exactly the same version of the toolchain, the same build
// tags, and the same values of certain flags and environment
// variables.
//
// - Similar crashing problems are likely to arise unless all common
// dependencies of the application and its plugins are built from
// exactly the same source code.
//
// - Together, these restrictions mean that, in practice, the
// application and its plugins must all be built together by a
// single person or component of a system. In that case, it may
// be simpler for that person or component to generate Go source
// files that blank-import the desired set of plugins and then
// compile a static executable in the usual way.
//
// For these reasons, many users decide that traditional interprocess
// communication (IPC) mechanisms such as sockets, pipes, remote
// procedure call (RPC), shared memory mappings, or file system
// operations may be more suitable despite the performance overheads.
package plugin
// Plugin is a loaded Go plugin.