On Tuesday 08 January 2002 01:39 pm, William A. Rowe, Jr. wrote: > From: "Ryan Bloom" <[EMAIL PROTECTED]> > Sent: Tuesday, January 08, 2002 3:04 PM > > > > On Tuesday 08 January 2002 12:41 pm, Mladen Turk wrote: > > > > From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> > > > Sent: Tuesday, January 08, 2002 8:53 PM > > > > > > > I'm also looking at the API and understand why you were worried about > > > > the > > > > anon. But what you describe is a hybrid, a named, anon shm. For now, > > > > we > > > > will be using backing files; adding both keyed and named create where > > > > the > > > > platform supports both is a reasonable potential improvement in the > > > > future. > > > > > > The reason for using a filename and a NAME for that file (that was my > > > initial post to Aaron) has nothing to do with the keyed/named created > > > shms. > > > Simply, the Apache could create whatever shmem file with some NAME, and > > > the > > > rest of the world can access it simply using that NAME. > > Windows names the backing file seperately from an attach()able shared segment. > Since this is file backed, we will create a 'flat' name (convert the colon and > slashes to some neutral character and truncate off the left to 255 chars), > and added to the W2K Terminal Server Global\ namespace. > > So Mladen, we address your concerns. Someday in the future, we could create > a 'named' anon (this is called 'keyed' in apr nomenclature) and it's up to > the processes to agree on an identity. Since the 'key' is an int, a simple > name like Local\apr_shm_##### would work. Again, that's a future improvement > :) > > > > I'm confused, the NAME is the filename. > > No, to the attach()er, it follows the schema above.
No. The whole point is that you have to have some way to communicate the name to the second process. You always use a file, and if you are dealing with key'ed shared memory, the file just contains the key. The second process just reads the file, gets the key, and does the attach. Ryan ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
