PK_MEMORY_block_t

struct PK_MEMORY_block_s
    {
    struct PK_MEMORY_block_s *next;
    size_t                    n_bytes;
    const char               *bytes;
    };
typedef struct PK_MEMORY_block_s PK_MEMORY_block_t;




This structure holds XT data.

Used in:

PK_MEMORY_block_f
PK_PART_receive_b
PK_PART_receive_version_b
PK_PART_transmit_b
PK_PARTITION_receive_b
PK_PARTITION_receive_o_t
PK_PARTITION_receive_version_b
PK_PARTITION_transmit_b

Memory blocks and in-memory I/O

Parasolid's archive model does not specify how XT data is preserved by
applications, though physical disk files are often used, with names
related to the key referred to by Parasolid. This implementation may not
be appropriate, e.g. an application may wish to keep its XT data as a
segment of a larger file, interleaved with non-Parasolid information, or,
over a network, XT data may be visible only as a chapter of an XML
document. Applications may use copies in temporary files, or replace the
registered Frustrum read/write routines (see PK_SESSION_register_frustrum),
but Parasolid's explicit in-memory routines remove the need for this.

The input routines PK_PART_receive_b and PK_PARTITION_receive_b take a
block of data, followed by more blocks if the XT data is in more than one
segment. Storage management is the application's responsibility.

The output routines PK_PART_transmit_b and PK_PARTITION_transmit_b
generate chains of blocks, using the PK memory allocators (see
PK_MEMORY_register_callbacks). As Parasolid uses a standard-sized memory
block (see PK_MEMORY_set_block_size) as a buffer to generate the XT data,
the size of individual blocks will approach, but not exceed, that size.
After processing, the application should use PK_MEMORY_block_f to free the
XT chains.