Hi,
An implementation is given in
https://issues.apache.org/jira/browse/AXIS2C-780
please check and apply the patch. comments are welcome.
regards,
Uthaiyashankar.
Uthaiyashankar wrote:
Hi Chris,
Thank you very much for the comment. For the initial phase, as you
advised, we'll proceed by allocating a large block without resizing.
Later on, we can implement the resizing logic.
Regards,
Uthaiyashankar
Chris Darroch wrote:
Uthaiyashankar wrote:
We can use global mutex to control the access of shared memory. An
example implementation is given in
http://people.apache.org/~sctemme/mod_example_ipc.c.
mod_ldap is also using a similar approach to cache and share data
between child processes.
However, to hide the low level details from service/module
implementers, we might have to write a wrapper to manage the shared
memory, growing/shrinking the shared memory according to the demand,
creating objects in shared memory, etc.
One caution: growing/shrinking shared memory is likely to be a
pretty complex operation, if it's even possible with certain
shared-memory
implementations. APR provides a number of different shared memory
options and chooses between them at compile-time; the only options
to the programmer are named-based vs. anonymous.
To resize the shared memory block, you'd probably need name-based
shared memory, first of all. The only way I can see resizing would
work is if all the processes coordinate; suppose, for example, that
process A acquires the global lock, it could then allocate a new
shared-memory block, copy all the data from the old one, and write
the filename associated with the new block into a special location
in the old one or communicate it somehow to all other processes;
they then need to attach to the new block and detach from the old block.
Depending on the underlying implementation, you might, I suppose,
need to also manage a reference count of how many processes are
still attached to the old block, and only destroy it when all had
attached to the new block; this of course gets complicated if a
process dies suddenly, etc.
This is why httpd, for its scoreboard, simply creates a large
shared memory segment at startup (based on compile-time limits)
and never tries to resize it.
A number of httpd modules already manage data in shared memory
segments (in one case, by borrowing part of the scoreboard, but
that's not ideal). I proposed, for httpd 3.0, some ideas about how
to try to abstract the subject of inter-process data sharing, such
that different providers could be plugged into a generic interface
(shared memory, memcache, etc.):
http://svn.apache.org/viewvc/httpd/sandbox/amsterdam/architecture/scoreboard.txt
I think Axis2/C might be a good candidate to be another user of
this mechanism ... but, of course, it exists only on paper so far.
With luck I'll get back to this in 2008; time permitting, of course!
Cheers,
Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
