Shared mem

[MattJaniszewski]

I ran into a limit when the FIFO pipe would get full (> ~62k of data), and cause the child processes to block until the pipe was cleared (e.g., by running the cat command in the appropriate FIFO handle on the file system). The use of the shmop_ functions seemed like a good alternative.

In the PR, I added a unit test which re-creates the problem that kept the original version from working on a typical Linux system.

One thing I will note is that while I did all the due-diligence I could with the shmop_ functions, I had to end up using @shmop_open with the error suppressor operator twice, to test for the presence for an existing memory segment. It's not ideal, but seemed like the only way.

A decent way to test that there are no left-over open memory segments is to run ipcs -m on the Linux system. You can then pass any offending shmid value over to the ipcrm binary. My testing as of yet indicated no issues of this kind, but it's theoretically possible it can happen in some edge-cases.

[seyfer]

:+1:

[githoober]

@MattJaniszewski: :+1:

[kriswallsmith]

Would you mind removing the PSR-2 commit (or moving it to another pull request) so that this pull request is limited to the shared memory change?

[MattJaniszewski]

I rebased this branch, and removed all the un-related modifications. I created separate branches for them, and I'll create the pull requests later (so they will end up being fast-forward merges).