🚀 go-pugleaf

I don't especially want to get into this discussion in deep technical
detail (partly because I probably don't *understand* deep detail),
but I don't want to let these conclusions stand without qualification.

In article <168@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>In article <3225@spim.mips.COM> cprice@mips.com (Charlie Price) writes:

... how the R4000 implements endian-ness...

>Then, shared memory between processes of different endian is impossible.
>
>This means that access to a file through memory mapping mechanism is
>impossible, if the file is accessed from processes of different endian.

You cannot share *arbitrary* binary data transparently through
either shared memory or the filesystem.

You *can* arrange to share ONE binary format.
I think the only reasonable one to pick is characters (i.e. bytes).
For data that processes share actively and access it frequently,
I suspect that you won't like the performance of mixed endian access,
but you can certainly make it *work*.

Your observation about simultaneous access to a mapped file is
essentially the same problem as shared data though shared segments.

For a non-native process using a mapped file, you ned to do the same
transform that you would for any unmapped I/O --
When a page is accessed, and mapped to the process,
the OS must swap the bytes around within the page so that
character-stream order is preserved.
This in-memory page is now in a special state and it has to be
transformed back to the native character-stream order before it
can be written back to disk.
If a memory-mapped file page or shared memory segment page is accessed
by processes that have different endian-ness, the page has to be put into
the proper character-stream order before the access can be granted.

This would be very expensive for highly-shared accesses,
so I suspect people won't do it very much.
Fortunately, most file access, mapped or otherwise, doesn't involve
a high degree of simultaneous access by several processes.
-- 
Charlie Price    cprice@mips.mips.com        (408) 720-1700
MIPS Computer Systems / 928 Arques Ave.  MS 1-03 / Sunnyvale, CA   94088-3650