httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eserio <>
Subject Re: [PHP-DEV] ANNOUNCE: MM library, version 1.0b1 (fwd)
Date Sat, 13 Mar 1999 16:15:05 GMT

> Currently I've implemented the following variants which already cover 95% of
> all current major Unix platforms AFAIK:
>   Shared Memory:
>   o Classical mmap() on temporary file
>   o SVR4-style mmap() on /dev/zero
>   o mmap() via POSIX.1 shm_open() on temporary file
>   o 4.4BSD-style mmap() via MAP_ANON
>   o SysV IPC shmget()
>   Mutex/Semaphore:
>   o 4.2BSD-style flock() on temporary file
>   o SVR4-style fcntl() on temporary file
>   o SysV IPC semget()

I don't know if this is already in the plans, but while you are at it you
could use this library to add support to PHP for named semaphores and
shared memory.

Currently the only way to share semaphores and shared memory keys between
two instances of the same PHP script run by different Apache threads is by
hardcoding key numbers in the script.

The way I see it this raises a problem regarding the availability of the
key.  It might happen once in a while that the hardcoded key number may
have been acquired by some other process besides the one that your PHP
script runs on.  This may be problematic because it may leave your script
waiting for a semaphore that is being hold by some other process to
arbitrate the access to a completely unrelated resource.

My suggestion is that instead of using hardcoded keys, there should be a
way to allocate a private key (IPC_PRIVATE).  So, if the script wants
acquire a semaphore/shared memory, it would pass a string that would be
used an index for an associative array of keys.

If there is no key associated to the given named index, the key allocation
code would allocate a new private key and would store it in the associative
array.  So, next time the script asks for the same named key, the same
private key would be fetched and returned.

Of course all the associative array of keys would have to be stored in
shared memory arbitrated with their own private set of semaphores.  So, the
shared memory/semaphore pools would come right in hand for the job.

Just let me know what do you think about this and if you think it is


View raw message