2

I'm working on a very small library to make asynchronous calls across PHP processes, and am experiencing some weird behaviour with regards to referencing objects (and arrays - the same issue happens whether referencing an object or array). The end result is that objects and arrays temporarily appear empty and I'm trying to find out why this happens.

The following image shows a trace of a script which spawns 3 children from the parent process. All output comes from the parent process (nothing leaks out to the terminal through the children). The parent process makes a series of requests to the child processes and receives responses via a pair FIFO pipes:

Script trace

  • A blue row indicates where the parent successfully and sent and received a response.
  • A red row indicates where the parent successfully sent and received the response, but upon receiving the response, the object in the parent containing the representions of the RPCs is mysteriously 'empty', so the action that should be associated with that RPC response can't be called because it can't be referenced.
  • A gold row shows precedes each success or failure, showing the state of the object which holds all the RPCs waiting for responses. The row contains the object ID (from scraping var_dump of object) and the keys it has (which are the ID of each RPC waiting for a response from the child).

The problem is illustrated as follows:

  1. In each of the green rings you can see we are referencing the identical object as this is the internal ID reference provided by PHP. In the first row with a green ring, the object has all the properties it should.

  2. In each of the red rings is the ID of the RPC that 'fails' because, in the second row with a green ring the object mysteriously empties.

  3. Later on in the process, in the third row with the green ring, the object magically has all its properties back again.

Notes:

  • This happens completely at random.
  • This also happens identically when using an array (I was originally using an array instead of an object and tried an object to see if it would work around this behaviour).
rthrfrd
  • 71
  • 4

0 Answers0