This commit fixes a race condition. This library uses a "pipe" flag to implement a sort of req/res assignment of local data [to an external ID].
The method is to store the data in a "pipe" queue, and pop this queue on the next received event. The issue [race condition] is when the next received event does not at all correspond to what we're waiting for.
Concretely in this case, we're sending a JOB_CREATE request, and the next immediate response is "WORK_STATUS".  The work status response clears our queue, and the subsequent JOB_CREATED response never gets hand shaken properly. As a short term fix, I've added a little more structure around which responses should pop the queue. This prevents the most obvious race condition that I was experiencing, but may not resolves everyone issue. A better fix would be to attach some unique ID to the request which can then be matched up with the response,but I'm not really familiar with Gearman protocol.