On 06/10/06, <b class="gmail_sendername">Julian Somers</b> <<a href="mailto:lists@bigpip.com">lists@bigpip.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 14:51 Thu 05 Oct     , - Tethys wrote:<br>> On 10/5/06, Julian Somers <<a href="mailto:lists@bigpip.com">lists@bigpip.com</a>> wrote:<br>><br>> >Bash can see my shared memory block with `ipcs`, and delete it with
<br>> >`ipcrm -M $shmkey`. Is there a way to read its contents?<br>><br>> Not off the top of my head, no. But it should be trivial to knock up a<br>> wrapper around shmat(3) that will give you access to shared memory
<br>> segments from a shell.<br><br>Since my C doesn't even stretch to knocking up a trivial wrapper, I have<br>made a php script that fetches the stuff out of shared memory for the<br>shell scripts. Probably more of a pass-the-parcel than a wrapper, but it
<br>works.<br><br>My understanding of shared memory is that I need to avoid simultaneous<br>writes, but don't need to worry about simultaneous reads. Is this the<br>case? And do I need to block anything from reading the memory while
<br>I'm writing to it?</blockquote><div><br>Can you not re-write your bash scripts in php?<br><br>#!/usr/bin/php works just the same. :-)<br><br>It's ok to have multiple readers, but reading memory that is being written to is normally to be avoided, and multiple writers to the same location is definitely to be avoided (but different parts of the same shared memory is of course ok).  You'd normally use some sort of locking mechanism, that is a thing that gets set atomically when you want to write to the shared memory.  When locked, the other processes should block until it is unset.  This can be implemented in any number of ways, from a semaphore to a lock file.
<br><br>Another approach is to use some sort of intermediary that has sole control of the memory through which all the other things get access.<br><br>Pete</div></div>