php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #7046 shm_put_var wont put the given var into memory
Submitted: 2000-10-05 19:31 UTC Modified: 2000-12-20 18:19 UTC
From: FaVo at FaVo dot li Assigned:
Status: Closed Package: Semaphore related
PHP Version: 4.0.2 OS: Linux version 2.2.13 (SuSE)
Private report: No CVE-ID: None
 [2000-10-05 19:31 UTC] FaVo at FaVo dot li
I was working with shared memory segments on PHP 4.0.2, it works fine.
But sometimes (ca. 5% of the calls) it wont put my array into the memory, after a second try sometimes third try with a timeout of 1ms it worked. 

Example Code:
                while (!$check_mem) {
                        shm_remove($shm_id);
                        $uid = shm_attach($shm_id, $global[ARRAY_SIZE]);
                        $tstamp = time();
                        $user_data = array (
                                "nick" => $cur_identity->username,
                                "channel" => $channel,
                                "input" => "",
                                "query" => "",
                                "query_stat" => "",
                                "cybernode" => $cur_identity->cybernode_key,
                                "timestamp" => $tstamp,
                                "color" => 2,
                                "channel_info" => 1,
                                "voice" => 1,
                                "level" => $user_level
                        );
                        $check_mem = shm_put_var($uid, $shm_id, $user_data);
                        if (!$check_mem) echo "*";
                        usleep(1);
                }

I needed the while-loop and usleep to check if it was successfull.
When i removed the usleep i had about 80 stars (*) sometimes, but worked after that many tries. With the usleep it just needs 2 sometimes 3 tries.
But its only at about 5% of the calls (tried this one with about 700 script calls after i saw it).

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-12-10 11:26 UTC] stas@php.net
Failed to reproduce. Does it stil happen on 4.0.3pl1/latest
snapshot? Can you give more info on where it fails (IDs,
sizes, errors, etc.)?
 [2000-12-20 15:16 UTC] FaVo at FaVo dot li
On PHP 4.0.3pl1 it seems to be fixed, but i had other problems like that.

BD> snapshot? Can you give more info on where it fails (IDs,
BD> sizes, errors, etc.)?
- the ID's were random int. (the strange thing was that it worked without changing the ID after some tries)
- just gave me the same error like when i were trying to create more segments than allowed on the system
- the requested size was about 10.000 bytes
     
     The other problem with shared memory (shm_get_var):
     I was reading the Array in a segment in a loop and on every action
     a user has made. The strange thing was, it was sometimes empty so
     that i needed to save some information local and restore it. I
     saw this after some 100 requests, there was no special number ..
     looked like it lost it randomly -- but for sure it happened when
     i readed, modified and saved it after a random number of changes (input of the user).

     The application we were working on has these steps:

     a) never ending loop for output - reading the shared memory every
        few ms
     b) input of the user - reading and modify of the segment if
        needed
     c) status - reading the segment every 20 seconds
     d) a third process - reading the data every minute
     
     These was the last problem after i started to write a small
     script that does that communication via socket with a
     never-ending-script. Its very slow on PHP, but going to do the
     same on perl now :/.

     If you need more detailed information for this problem, i could
     take a look at the old sources.

 [2000-12-20 18:19 UTC] sniper@php.net
fixed -> closed.

--Jani
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 06:01:30 2024 UTC