[Simh] Unable to build on NetBSD

[Rhialto]

On Tue 28 Apr 2015 at 16:44:53 -0700, Mark Pizzolato - Info Comm wrote:
> 
> Are you suggesting that the memory reference semantics (and coherency
> concerns) when using a mmap'ed shared memory area (between two or more
> processes) is NOT equivalent to multiple threads in the same process
> referencing the same data in their single address space?

One would hope that it IS equivalent. But I've been searching for
guarantees that it is and so far I haven't been able to actually find
any! I suspect that the authors of the text I've seen deemed it too
obvious to spell out, but I'm too careful to want to rely on that
theory.

I started out with manual pages, but of course the text of a relevant
Standard would be better. So I looked at
http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html
which is hopefully a good place to start. On the positive side, it says
this:

    MAP_SHARED and MAP_PRIVATE describe the disposition of write
    references to the memory object. If MAP_SHARED is specified, write
    references shall change the underlying object.

However it does /not/ say that this shall happen /immediately/ or
somesuch. The remainder of the page remains silent on the topic. Nothing
forbids a perverse implementation to copy stuff over only every now and
then, by my reading.

This thought isn't so far-fetched, since this is exactly what happens to
the contents of the file: you need to call msync(2) to update the file.

Maybe I'm too paranoid though, but in the past I've been reading
comp.std.c and the language-lawyering that goes on in there, and that
makes one very careful not to rely on a promise that isn't clearly
spelled out.

On the positive side, files as opened with shm_open() are called "shared
memory objects" and are not deemed to be files (you can only use
ftruncate(2) and mmap(2) on them). So even if still no promises are made
here, any limitations that are related to mmapping files would not
apply.

I wonder where an authoritative answer can be found that is actually
spelled out.

> Aside from my above question, thanks for the fix for the X11R7 issue
> with the makefile.
> 
> Meanwhile, Cory's original simh building problem has been fixed in the
> github master branch.

Great!

> - Mark
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl    -- 'this bath is too hot.'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150429/49cf1c0e/attachment.sig>