view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        PIPE_BUF is 4096 bytes.) [...]

    Under the hood this module will split your message into small sections
    of slightly smaller than the PIPE_BUF limit. Each section is sent as 1
    atomic chunk with a 16 byte header consisting of four 32-bit fields:
    the process id it came from, the thread id it came from, a chunk ID (in
    descending order, so if there are 3 chunks the first will have id 2,
    the second 1, and the final chunk is always 0 allowing a flush as it
    knows it is done) and the length of the data section to follow.

    NOTE: Payloads are byte strings. If you have a wide-character (unicode)
    string, encode it (e.g. with "encode" in Encode) before passing it to
    write_message() or write_burst(); decode on the read side.

    On the receiving end this module will read chunks and re-assemble them
    based on the header data. So the reader will always get complete
    messages. Note that message order is not guaranteed when messages are
    sent from multiple processes or threads. Though all messages from any
    given thread/process should be in order.

SYNOPSIS

README.md  view on Meta::CPAN

    PIPE_BUF is 4096 bytes.) [...]

Under the hood this module will split your message into small sections of
slightly smaller than the PIPE\_BUF limit. Each section is sent as 1 atomic
chunk with a 16 byte header consisting of four 32-bit fields: the process id it
came from, the thread id it came from, a chunk ID (in descending order, so if
there are 3 chunks the first will have id 2, the second 1, and the final chunk
is always 0 allowing a flush as it knows it is done) and the length of the data
section to follow.

**NOTE:** Payloads are byte strings. If you have a wide-character (unicode)
string, encode it (e.g. with ["encode" in Encode](https://metacpan.org/pod/Encode#encode)) before passing it to
`write_message()` or `write_burst()`; decode on the read side.

On the receiving end this module will read chunks and re-assemble them based on
the header data. So the reader will always get complete messages. Note that
message order is not guaranteed when messages are sent from multiple processes
or threads. Though all messages from any given thread/process should be in
order.

# SYNOPSIS

lib/Atomic/Pipe.pm  view on Meta::CPAN

    PIPE_BUF is 4096 bytes.) [...]

Under the hood this module will split your message into small sections of
slightly smaller than the PIPE_BUF limit. Each section is sent as 1 atomic
chunk with a 16 byte header consisting of four 32-bit fields: the process id it
came from, the thread id it came from, a chunk ID (in descending order, so if
there are 3 chunks the first will have id 2, the second 1, and the final chunk
is always 0 allowing a flush as it knows it is done) and the length of the data
section to follow.

B<NOTE:> Payloads are byte strings. If you have a wide-character (unicode)
string, encode it (e.g. with L<Encode/encode>) before passing it to
C<write_message()> or C<write_burst()>; decode on the read side.

On the receiving end this module will read chunks and re-assemble them based on
the header data. So the reader will always get complete messages. Note that
message order is not guaranteed when messages are sent from multiple processes
or threads. Though all messages from any given thread/process should be in
order.

=head1 SYNOPSIS