Hash-SharedMem

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

  * no longer include a Makefile.PL in the distribution

  * in documentation, use four-column indentation for all verbatim
    material

  * in META.{yml,json}, point to public bug tracker

  * rewrite some internal recursive functions to use the cursor system

  * to perform static assertion in C, rather than a hand-crafted
    formulation, use Perl's STATIC_ASSERT_DECL() macro (from Perl 5.27.1
    onwards) or STATIC_ASSERT_GLOBAL() macro (from Perl 5.21.7 until it
    was renamed to STATIC_ASSERT_DECL()), with a reserve definition for
    older Perls

  * avoid some compiler warnings that arise on Perl 5.6

  * use cBOOL() where appropriate

  * remove a duplicated assignment statement

DESIGN  view on Meta::CPAN

endianness) are encapsulated as a word quantity, in which bits are
allocated thus:

	0-7   log2(line/byte)
	8-15  log2(page/byte)
	16-23 MAXFANOUT
	24-63 zero padding

If, in the future, there is any change in the file formats, it should be
indicated by setting bits in what is currently zero padding.  This might
be formulated as setting bit flags, or as changing a version number.
ext2's concept of readonly-compatible changes may be useful, but
comprehensibility of a shash to old code is not generally a priority.

A data file begins with this header:

	* word: magic number 0xc693dac5ed5e47c2

	* word: design parameters

	* word: total file length in bytes (must be page-aligned, and

lib/Hash/SharedMem.xs  view on Meta::CPAN

	 * The memory allocations of interest are one XPV and the
	 * buffer for copying, and one XPVMG and one MAGIC for mapping.
	 * The ugly expression here tries to compare the two sets of
	 * allocations.  The XPVMG+MAGIC - XPV difference is compared
	 * against the potential buffer size.  It is presumed that the
	 * buffer length will be rounded up to a word-aligned size.
	 * The structure size difference is rounded up in an attempt to
	 * find a threshold likely to be used by the memory allocator.
	 * Ideally this would be rounded to the next power of 2, but we
	 * can't implement that in a constant expression, so it's actually
	 * rounded to the next multiple of the XPVMG size.  The formula
	 * is slightly contrived so as to achieve the exact 120-octet
	 * threshold on the amd64 system used for speed trials (where
	 * MAGIC is 40 octets, XPV is 32 octets, and XPVMG is 64 octets).
	 */
	if(pvl.len < sizeof(XPVMG) *
			((sizeof(MAGIC)+sizeof(XPVMG)*2-1) / sizeof(XPVMG)) -
			sizeof(size_t)) {
		sv = newSVpvn_mortal(pvl.pv, pvl.len);
	} else {
		sv = sv_2mortal(newSV_type(SVt_PVMG));

lib/Hash/SharedMem.xs  view on Meta::CPAN

			 * of the minimally-filled node (WORD_SZ *
			 * (1+2*MINFANOUT)) divided by MINFANOUT-1;
			 * we round this up to an integral number of
			 * bytes per entry.
			 *
			 * Nodes that are more than minimally filled lead
			 * to this being an overestimate, because they
			 * are more space-efficient both in themselves
			 * and by using fewer higher-layer entries.
			 * An underfilled root node can lead to needing
			 * more bytes than this formula allows, but the
			 * space allowed for the node will always be
			 * strictly greater than the two words per entry
			 * required by the node body.  Because the size
			 * is ultimately rounded up to word alignment
			 * (actually to line alignment), it is rounded
			 * up sufficiently to account for the single-word
			 * header of the root node.
			 */
			asz = cur.ent[0].fanout *
				((WORD_SZ*(1+2*MINFANOUT) + MINFANOUT-2) /