Expected initial sequence of events for Pipe usage:

1. Pipe is created in parent process (read and write ends open)
2. Parent process forks
3. An after_fork hook is invoked in the child
4. From after_fork hook, child closes read end of pipe, and writes a ready marker on the pipe (after_fork_in_child).
5. The parent receives the ready marker, and closes the write end of the pipe in response (after_fork_in_parent).

After this sequence of steps, an exit (whether clean or not) of the child will result in the pipe being marked readable again, and giving an EOF marker (nil) when read. Note that closing of the unused ends of the pipe in the parent and child processes is essential in order for the EOF to be correctly triggered. The ready marker mechanism is used because there‘s no easy hook for after_fork in the parent process.

This class provides message framing (separation of individual messages), but not serialization. Serialization / deserialization is the responsibility of clients.

Message framing works like this:

Each message sent across the pipe is preceded by a length tag that specifies the length of the message that immediately follows, in bytes. The length tags are serialized as unsigned big-endian long values, (4 bytes each). This means that the maximum theoretical message size is 4 GB - much larger than we‘d ever need or want for this application.