// the file used by ftok. can be any file.
$shmop_file = "/usr/bin/php8.3";
for($i = 0; $i < 4; $i++) {
// create the fork
$pid = pcntl_fork();
// an error has ocurred
if($pid === -1) {
echo "error".PHP_EOL;
}
// child process
else if(!$pid) {
// create a random 'word' for this child to write to shared memory
$random_word = join(array_map(fn($n) => range('a', 'z')[rand(0, 25)], range(1,5)));
// write to shmop
$shm_key = ftok($shmop_file, $i);
$shm_id = shmop_open($shm_key, 'n', 0755, 1024);
shmop_write($shm_id, $random_word, 0);
print "child $i wrote '$random_word' to shmop".PHP_EOL;
// terminate the child process
exit(0);
}
}
// wait for all child processes to finish
while(($pid = pcntl_waitpid(0, $status)) != -1) {
echo "pid $pid finished".PHP_EOL;
}
// read all our shared memories
for($i = 0; $i < 4; $i++) {
// recreate the shm key
$shm_key = ftok($shmop_file, $i);
// read from the shared memory
$shm_id = shmop_open($shm_key, 'a', 0755, 1024);
$shmop_contents = shmop_read($shm_id, 0, 1024);
print "reading '$shmop_contents' from child $i".PHP_EOL;
// delete the shared memory so the shm key can be reused in future runs of this script
shmop_delete($shm_id);
}
the mode argument that we pass to shmop_open determines how we can access our shared memory block. there are four options, all covered in the official documentation, but for the sake of simplicity, we'll only look at the two we need for our purposes.
n : the 'n' stands for 'new' and is used when we want to create a new shared memory block. there does exist a mode c for 'create', but we are choosing to use n here because this mode will fail if we try to open a memory block that already exists. that's a safety feature! in fact, the docs state that using n to create a new shared memory block is 'useful' for 'security purposes'. the pointer returned from shmop_open using mode n is writeable.
a : this is for 'access'; ie. reading. do not confuse this with fopen's a mode, which is for 'append'. memory blocks opened with mode a are read-only.
if we look at the example, we can see that when we open the shared memory block in the child process to write our data, we use the n mode. this creates the new memory block in a safe way and returns a pointer that we can write to.
using shmop_write to... write.
once our child process has created a new shared memory block and received a pointer to it, it can write whatever it wants there using shmop_write.
in our example, doing this looks like:
shmop_write($shm_id, $random_word, 0);
登入後複製
the shmop_write function takes three arguments:
the pointer: the pointer returned from shmop_open. note that shmop_open must be called with a mode that allows writing (n in our example), otherwise attempts to use shmop_write will fail.
the value to write: the string to write to the shared memory block.
the offset: the number of bytes in memory to offset the start point of the write by. using the offset can allow us to append to a value already in the shared memory block, but doing this means keeping track of bytes written and can become unmanageable pretty quickly. in our example, we use the offset 0; we start writing at the beginning of the memory block.
shmop_write returns, as an integer, the number of bytes written.
a short note about shmop_close
if you've done file access using fopen, you're probably (hopefully!) in the habit of calling fclose when you're done writing.
we do not do that with shmop.
there is a shmop_close function, but it has been deprecated since php 8.0 and does nothing (other than throw a deprecation warning, that is). the standard practice with shmop is to just leave the pointer 'open' after we're done writing. we'll delete it later.
reading from shared memory
once all the child processes have written their data to their respective shared memory blocks an exited, all that remains is for the parent process to read that data. the strategy for this is:
recreate the key of the shared memory block
use the key to open the shared memory in 'access only' mode
read the data into a variable
let's look again at the example we have for reading shared memory.
// read all our shared memories
for($i = 0; $i < 4; $i++) {
// recreate the shm key
$shm_key = ftok($shmop_file, $i);
// read from the shared memory
$shm_id = shmop_open($shm_key, 'a', 0755, 1024);
$shmop_contents = shmop_read($shm_id, 0, 1024);
print "reading '$shmop_contents' from child $i".PHP_EOL;
// delete the shared memory so the shm key can be reused in future runs of this script
shmop_delete($shm_id);
}
登入後複製
recreating the shmop key
when we made the key to create our shared memory blocks, we used ftok with two arguments: the path an existing file in the filesystem, and a 'project id'. for the project id, we used the index of the array we looped over to fork multiple children.
we can use the exact same strategy to recreate the keys for reading. as long as we input the same two arguments into ftok, we get the same value back.
opening the shared memory
we open the shared memory block for reading almost exactly the same way as we did above for writing. the only difference is the mode.
for reading, we use the a mode. this stands for 'access', and gives us a read-only pointer to our shared memory block.
reading from the shared memory block
once we have a pointer to our shared memory block, we can read from it using shmop_read.
shmop_read takes three arguments:
the pointer we got from shmop_open.
the offset, in bytes. since we are reading the entirety of the memory block, starting at the beginning, this is 0 in our example (and will probably be for most real-life uses, as well)
the number of bytes to read. in most cases, the smart thing here is to just read the entire size of the block, in our example 1024 bytes.
the return type is a string. if there are errors reading, we get a boolean false.
deleting shared memory blocks
once we are done reading our shared memory, we can delete it.
this is an important step. unlike variables in our script, the memory we assigned with shmop will persist after our program has exited, hogging resources. we do not want to litter our system with blocks of unused, reserved memory, piling up higher and higher with each successive run of our script!
freeing up shared memory blocks is done with shmop_delete. this function takes one argument: the pointer we created with shmop_open, and returns a boolean true on success.
note that shmop_delete destroys the memory block and frees up the space for other applications to use. we should only call it when we're completely done with using the memory.
handling errors
the example we've been going over doesn't really do any error handling. this is a decision borne out of a desire for brevity, not delusional optimism. in real applications we should certainly do some error testing!
we used a path to a file as an argument for ftok; we should test that it exists. shmop_write will throw a value error if our memory block is opened read-only or we overwrite its size. that should be handled. if there's a problem reading data, shmop_read will return false. test for that.
i am asking you to do some error handling
fixing 'already exists' errors with shmop_open
if we open a shared memory block and then the script terminates before we call shmop_delete, the memory block still exists. if we then try to open that memory block again with shmop_open using the n mode, we will get the error:
PHP Warning: shmop_open(): Unable to attach or create shared memory segment "File exists" in /path/to/my/script on line <line number>
登入後複製
if our script is well-designed, this shouldn't happen. but, while developing and testing we may create these orphaned memory blocks. let's go over how to delete them.
the first step is to get the key of the memory block as a hex number. we do this by calling ftok as normal, and then converting the returned integer from base ten to base-16 like so:
we do this because linux comes with a number of 'interprocess communication' tools that we can use to manage shared memory blocks, and they all use hexadecimal numbers for their keys.
the first command line tool we'll use is ipcs. we're going to use this to confirm that the shared memory block we want to delete does, in fact, exist.
the ipcs command, when run without arguments, will output all interprocess communication channels, including all shared memory blocks. we'll narrow down that output by using grep with the hexadecimal key we created above. for instance, if our shared memory block's key in hexadecimal is 0x33010024, we could do this:
ipcs | grep "0x33010024"
登入後複製
if we get a line of output, the memory block exists. if nothing is returned, it does not.
once we've confirm that a shared memory block exists, we can remove it with ipcrm
ipcrm --shmem-key 0x33010024
登入後複製
knowing how to inspect and clean up (without resorting to a restart) shared memory allows us to develop and experiment without turning our ram into a ghost town of abandoned blocks.
wrapping up
achieving concurrency in php using fork and shared memory does take some effort and knowledge (and the official manual is scant help). but it does work and, if you've made it through this article and the first installment on pcntl_fork, you should have a good base from which to start.
? this post originally appeared in the grant horwood technical blog
