peter@ficc.ferranti.com (Peter da Silva) (05/23/90)
From: peter@ficc.ferranti.com (Peter da Silva) [ in the real world there are programmers who aren always as sensitive to portability issues as they should be ] > I like to think I'm working in the real world, and because I do care > about application portability I'm careful about these things when I > program. I suspect I'm not the only one. You and I will do that. But the people whose code I find myself maintaining are not always quite so careful. They generally try to conform to the standard as far as they know it, but aren't willing to go back to the base document to check on stuff they're sure is correct. > Note that there IS no magic > road to guaranteed portability, if the programmer is oblivious to the > issues. Not oblivious. Just not as sensitive as they should be. Say, someone trying to maintain a program that uses mmap(). Suddenly they need to save state, so they put the arguments in to map the whole file in. Six months later, when time comes to integrate this code back to the baseline it breaks on some machine that doesn't have a real mmap(). I don't want a magic road, but the signposts should at least be clear. [ extensions should require some magic juju before they're active, like calling mmap instead of shmmap ] > That would be nice, but it's pretty hard to enforce in cases like > adding extended functionality to the standard functions. Such as? -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.ferranti.com> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf. Volume-Number: Volume 20, Number 15
mikes@oakhill.sps.mot.com (Mike Schultz) (05/23/90)
From: mikes@oakhill.sps.mot.com (Mike Schultz) In article <700@longway.TIC.COM> From: karish@mindcrf.uucp >In article <696@longway.TIC.COM> [Doug Gwyn] writes: >>Like calling mmap() instead of whatever the POSIX routine is. > >I hope we don't have to name a new interface every time a new standard >restricts or changes the syntax of an old one. Especially when the >old interface is difficult to use portably anyway. I can't tell if you are for or against the use of the new interface, especially with the comment about the "difficult to use portably anyway" comment. The reason that the new interface was choosen is this: For REAL TIME purposes, shared memory functionality is very useful, but REQUIRING it to map files would be unacceptable for many implementations. Even the suggestion that the file would be on a RAM disk is not acceptable. The application should be able to request the shared memory to be mapped in and that is the LAST thing that the operating system should HAVE to do with it. Thus P1003.4 needed an interface that did not require that files be mapped. Mmap was existing practice, but it would have to be gutted in order to used it. It was felt that there was two courses to take here, both of which was certain to draw ballot objections. The solution choosen was one that was a subset of mmap's functionality, but was not the same interface. This had two advantages: First, it could be implemented with mmap using macros. Second, if an implementation wished to contain a pure shared memory interface, without routing it thru the blasted file system, it could do that as well as implementing mmap. Anyway, that was the reasoning then. Now here are the latest developments. SVR4 has taken the step of implementing mmap without requiring it to be a file. It states that one is mapping in a virtual memory object instead. It may be possible for the SVR4 wording of mmap to be used as existing practice. There will have to be some functionality labeled as implementation defined. We'll see how it goes. Mike Schultz mikes@oakhill.mot.sps.com And soon to be ms@RMC.Liant.com Volume-Number: Volume 20, Number 16
Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (06/11/90)
From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips)
>>>>> On 23 May 90 16:31:58 GMT, mikes@oakhill.sps.mot.com (Mike Schultz) said:
Mike> For REAL TIME purposes, shared memory functionality is very useful, but
Mike> REQUIRING it to map files would be unacceptable for many implementations.
It *seems* to me that directly implementing mmap() with SVr4 semantics
under VMS, AGEIS (and of course Multics :-) would be possible. UNIX
appears to be the late comer with shared memory. Am I missing something?
Mike> ...
Mike> Now here are the latest developments. SVR4 has taken the step of
Mike> implementing mmap without requiring it to be a file. It states that one
Mike> is mapping in a virtual memory object instead. It may be possible for
Mike> the SVR4 wording of mmap to be used as existing practice. There will
Mike> have to be some functionality labeled as implementation defined.
Regarding IPC and mmap():
If I understand the SVr4 implementation of mmap() correctly, it is only
possible to share write enabled memory between processes if mmap()ing a
file system file, but not possible using "anonymous" (a.k.a. swap) memory.
Is it possible, and if it is possible, are you restricted to sharing
anonymous memory between parent and child processes due to lack of a
file system handle?
In any case, is (or are there plans for) one of the POSIX groups to address
mmap() (or whatever it will be called) specificly as a method of IPC? It
appears SVr4 shared memory (shmat(), et al) offers little mmap() does not
(or couldn't easily be added, like handles).
Sorry if this posting is redundant. We only recently started recieving a
full comp.* feed.
Thanks in advance,
--
Chuck Phillips MS440
NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com
Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp
Volume-Number: Volume 20, Number 29mikes@sybil.uucp (Mike Schultz) (07/02/90)
From: mikes@sybil.uucp (Mike Schultz) [ I thought I posted this one a couple weeks ago, but apparently I missed it while I was at USENIX. Sorry about that. -mod ] > From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) > > It *seems* to me that directly implementing mmap() with SVr4 semantics > under VMS, AGEIS (and of course Multics :-) would be possible. UNIX > appears to be the late comer with shared memory. Am I missing something? Yes, imbedded controllers that may not have a real file system. > Regarding IPC and mmap(): > > If I understand the SVr4 implementation of mmap() correctly, it is only > possible to share write enabled memory between processes if mmap()ing a > file system file, but not possible using "anonymous" (a.k.a. swap) memory. > Is it possible, and if it is possible, are you restricted to sharing > anonymous memory between parent and child processes due to lack of a > file system handle? I'm afraid that I don't understand your question here. It is .4's specific goal to not restrict which processes have access to the shared memory. > In any case, is (or are there plans for) one of the POSIX groups to address > mmap() (or whatever it will be called) specificly as a method of IPC? It > appears SVr4 shared memory (shmat(), et al) offers little mmap() does not > (or couldn't easily be added, like handles). I don't know. Mike Schultz sybil!mikes@oakhill.sps.mot.com Volume-Number: Volume 20, Number 78