mirror of
https://github.com/golang/go
synced 2024-09-29 09:34:28 -06:00
plugin: add warning
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:
parent
72fdecafc0
commit
ee56b3c510
@ -13,8 +13,56 @@
|
|||||||
// already part of the program are called. The main function is not run.
|
// already part of the program are called. The main function is not run.
|
||||||
// A plugin is only initialized once, and cannot be closed.
|
// A plugin is only initialized once, and cannot be closed.
|
||||||
//
|
//
|
||||||
// Currently plugins are only supported on Linux, FreeBSD, and macOS.
|
// # Warnings
|
||||||
// Please report any issues.
|
//
|
||||||
|
// 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
|
package plugin
|
||||||
|
|
||||||
// Plugin is a loaded Go plugin.
|
// Plugin is a loaded Go plugin.
|
||||||
|
Loading…
Reference in New Issue
Block a user