Package Usage: go: modernc.org/lldb
Package lldb implements a low level database engine. The database model used
could be considered a specific implementation of some small(est)
intersection of models listed in [1]. As a settled term is lacking, it'll be
called here a 'Virtual memory model' (VMM).
2016-07-24: v1.0.4 brings some performance improvements.
2016-07-22: v1.0.3 brings some small performance improvements.
2016-07-12: v1.0.2 now uses packages from modernc.org/internal.
2016-07-12: v1.0.1 adds a license for testdata/fortunes.txt.
2016-07-11: First standalone release v1.0.0 of the package previously
published as experimental (modernc.org/exp/lldb).
A Filer is an abstraction of storage. A Filer may be a part of some process'
virtual address space, an OS file, a networked, remote file etc. Persistence
of the storage is optional, opaque to VMM and it is specific to a concrete
Filer implementation.
Mechanism to allocate, reallocate (resize), deallocate (and later reclaim
the unused) contiguous parts of a Filer, called blocks. Blocks are
identified and referred to by a handle, an int64.
In addition to the VMM like services, lldb provides volatile and
non-volatile BTrees. Keys and values of a BTree are limited in size to 64kB
each (a bit more actually). Support for larger keys/values, if desired, can
be built atop a BTree to certain limits.
A handle is the abstracted storage counterpart of a memory address. There
is one fundamental difference, though. Resizing a block never results in a
change to the handle which refers to the resized block, so a handle is more
akin to an unique numeric id/key. Yet it shares one property of pointers -
handles can be associated again with blocks after the original handle block
was deallocated. In other words, a handle uniqueness domain is the state of
the database and is not something comparable to e.g. an ever growing
numbering sequence.
Also, as with memory pointers, dangling handles can be created and blocks
overwritten when such handles are used. Using a zero handle to refer to a
block will not panic; however, the resulting error is effectively the same
exceptional situation as dereferencing a nil pointer.
Allocated/used blocks, are limited in size to only a little bit more than
64kB. Bigger semantic entities/structures must be built in lldb's client
code. The content of a block has no semantics attached, it's only a fully
opaque `[]byte`.
Use of "scalars" applies to EncodeScalars, DecodeScalars and Collate. Those
first two "to bytes" and "from bytes" functions are suggested for handling
multi-valued Allocator content items and/or keys/values of BTrees (using
Collate for keys). Types called "scalar" are:
Included are concrete implementations of some of the VMM interfaces included
to ease serving simple client code or for testing and possibly as an
example. More details in the documentation of such implementations.
9 versions
Latest release: almost 2 years ago
254 dependent packages
View more package details: https://packages.ecosystem.code.gouv.fr/registries/proxy.golang.org/packages/modernc.org/lldb
Dependent Repos 7
go-hep/hep
hep is the mono repository holding all of go-hep.org/x/hep packages and toolsLast synced: 7 months ago