ped@ahuta.UUCP (p.davidson) (04/03/85)
How do you pass a key from one process to another process so that both processes have acess to the same "shmid"? In other words how do you insure that each process has the same shared memory id?
ped@ahuta.UUCP (p.davidson) (04/03/85)
With shared memory, If the process that first created or reserved the memory exits/terminates can another process still access what ever was in that memory?
dave@uwvax.UUCP (Dave Cohrs) (04/04/85)
> How do you pass a key from one process to > another process so that both processes have acess to the > same "shmid"? > In other words how do you insure that each > process has the same shared memory id? I have implemented the SysV shared memory (well, not very well, but it works like the man pages describe) under 4.2BSD. In one application, we open up a server socket and the process with wants the same shmid connects to this and gets it. If you don't have these neat 4.2 functions, I'd suggest sending the shmid through a pipe to the other process or, if they aren't parent and child, make a famous file and put it there. dave -- dave cohrs ...!{allegra,harvard,ihnp4,seismo}!uwvax!dave dave@wisc-limburger.arpa (bug? what bug? that's a feature!)
dave@uwvax.UUCP (Dave Cohrs) (04/04/85)
> With shared memory, If the process that first created or > reserved the memory exits/terminates can another process > still access what ever was in that memory? The shared memory partition is not actually deallocated until a shmctl() is done to deallocate it. -- dave cohrs ...!{allegra,harvard,ihnp4,seismo}!uwvax!dave dave@wisc-limburger.arpa (bug? what bug? that's a feature!)
john@genrad.UUCP (John Nelson) (04/05/85)
>> With shared memory, If the process that first created or >> reserved the memory exits/terminates can another process >> still access what ever was in that memory? > >The shared memory partition is not actually deallocated until a shmctl() >is done to deallocate it. > Actually, the shared memory partition is not deallocated until a shmctl() is done to destroy it, and all the current users of that partition have released it (or terminated). Note that after the shmctl that destroys the partition, no new process can attach to that segment.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (04/06/85)
> How do you pass a key from one process to > another process so that both processes have acess to the > same "shmid"? Message passing?
tim@cithep.UucP (Tim Smith ) (04/07/85)
Shared memory stays around when the creator dies. Someone has to explicitly
ask it to go away.
As for passing the key to another proc, how about msg(2)? :-) :-) :-)
--
Duty Now for the Future
Tim Smith
ihnp4!{wlbr!callan,cithep}!timmjs@eagle.UUCP (M.J.Shannon) (04/09/85)
> > How do you pass a key from one process to > > another process so that both processes have acess to the > > same "shmid"? > > Message passing? The "proper" way to do this is to use the ftok() (stdipc(3C)) routine with a filename that all processes involved agree upon. Yes, it is difficult to find this routine (due to the name of the manual entry and the contents of the NAME section, it doesn't appear anywhere useful in the permuted index), but that's how to do it. Honest -- I've used it! -- Marty Shannon UUCP: ihnp4!eagle!mjs Phone: +1 201 522 6063
liang@cvl.UUCP (Eli Liang) (04/15/85)
..... I am posting this for a friend, whose Vax hasn't come in yet... :-) > > > How do you pass a key from one process to > > > another process so that both processes have acess to the > > > same "shmid"? > > > > Message passing? > > The "proper" way to do this is to use the ftok() (stdipc(3C)) routine > with a filename that all processes involved agree upon. Yes, it is > difficult to find this routine (due to the name of the manual entry > and the contents of the NAME section, it doesn't appear anywhere > useful in the permuted index), but that's how to do it. Honest -- > I've used it! > -- > Marty Shannon I am writing a multi-processing version of lisp in which one lisp process can ask another to evaluate an s-expression for the first. In order to keep things working properly, each of these `remote evaluations' should be it's own process (what's important is that it has it's own stack area, I'm willing to do my own process scheduling, but would rather not...), but they must share a single program segment (no problem) and a single data segment (problem). The above article from mod.unix seems to be about what I'm trying to do, but I have been unable to find ANY references in our on-line documentation to ftok() or sdtipc... Are they for 4.2BSC, or Sys V, or what? We're running 4.2, but I will also need to get this running on Dec ULTRIX (a carbon copy of 4.2, or so I'm told...) in the near future. vfork() seems to do part of what I want, but I cannot allow the parent process to be blocked for the duration of the child's execution. I would appreciate any ideas on the subject, or info about the above commands (how to get the doc would be sufficient), and will post summaries of any interesting suggestions I recieve. Thanks for the help.... Eric Messick reply by mail to: {seismo, allegra, brl-bmp}!umcp-cs!cvl!liang ------------------ any opinions expressed above do not literally exist within this universe..... -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eli Liang --- University of Maryland Computer Vision Lab, (301) 454-4526 ARPA: liang@cvl, liang@lemuria, eli@mit-mc, eli@mit-prep CSNET: liang@cvl UUCP: {seismo,allegra,brl-bmd}!umcp-cs!cvl!liang
duane@anasazi.UUCP (Duane Morse) (04/23/85)
> > > > > How do you pass a key from one process to > > > > another process so that both processes have acess to the > > > > same "shmid"? > The above article from mod.unix seems > to be about what I'm trying to do, but I have been unable to find ANY > references in our on-line documentation to ftok() or sdtipc... Are they > for 4.2BSC, or Sys V, or what? We had the same need and essentially invented ftok before we stumbled across it. The basic idea is to create a file and to use the file's inode number (with the possible addition of a identifying character) as the key for a shared memory segment. Unix guarantees that the inode number will be unique within a file system, so as long as all of your shared memory "files" are on the same file system, you shouldn't have any problem with duplicate keys. Further, since only the inode number of the shared memory "file" is needed, the file itself can be of 0 length, thus saving 1K that would otherwise be allocated. The addition of an identifying character to the full key (inode numbers are shorts, so you have another 16 bits to play with in the shared memory key) serves two purposes. First, it may be needed to avoid conflicts with shared memory keys that don't follow the above scheme. Second, it provides flexibility in your naming conventions. For instance, perhaps it would be more convenient for you to have only one shared memory "file" and a number of different identifiers for different memory segments. Duane Morse International Anasazi @ Phoenix "file" is
jsdy@hadron.UUCP (Joseph S. D. Yao) (05/07/85)
> ... I have been unable to find ANY > references in our on-line documentation to ftok() or sdtipc... Are they > for 4.2BSC, or Sys V, or what? We're running 4.2, but I will also need > to get this running on Dec ULTRIX (a carbon copy of 4.2, or so I'm told...) > in the near future. These routines refer to the shared-memory routines in System IV and System V. Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}