开发者

PHP Semaphores causing failures?

Our web servers have seen random PHP request failures for some requests that involve semaphores. We traced and suspected the request died somewhere due to sem_*() functions in PHP but we were unable to dig anything useful from the error log. We are on PHP 5.3.6 on 64-bit Linux machines. The code runs like this:

    $sem_id = @sem_get(123457, 1);
    if (!$sem_id) return;
    $sem_retval = @sem_acquire($sem_id);
    if (!$sem_retval) return;
    $shm_id = shmop_open(ftok('/some/path', 'h'), 'c', 0666, 8192);
    if ($shm_id === FALSE) { @sem_release($sem_id); return; }
    $str = shmop_read($shm_id, 0, 8192);
    // ... some operations that may result in changes to $data
    if ($data_updated) {
        shmop_write($shm_id, str_pad(serialize($data), 8192开发者_如何转开发, "\0"), 0);
    }
    @shmop_close($shm_id);
    @sem_release($sem_id);
    @sem_remove($sem_id);

This snippet is in an area having very frequent access with concurrency. In fact this is placed in a StreamWrapper implementation we developed internally for supporting our own operations. It appears like concurrency is related because we tested sequentially and did not reveal any issues.

Any insights as to what may be the cause? Also, I am not sure what sem_remove() is doing as I found no system call counterpart.

P.S. We took away all statements that contain sem_*() and seems like we no longer experience the issue.


You need to STOP using the @-operator, right away. This masks any error, and makes it silently ignored, even if it causes a fatal exit.

The @ operator is one of the worst features of PHP.

If an error happens, because you're using the @ operator, you've got no way of knowing what it was, or even that it happened at all, because your script will either plough on regardless, or exit with no dignostic data. This applies even if you've got error logging set up and error_reporting set to its maximum.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜