The Memory File

17 views
Skip to first unread message

luserdroog

unread,
Nov 27, 2016, 8:19:39 PM11/27/16
to xpost-discuss
The Xpost_Memory_File data structure and supporting code are a big rats-nest of #ifdefs and workarounds that permit some useful flexibility:

  uses mmap and mremap if available for fast management of big pages of data

  uses mmap, simulating mremap for half-fast management

  uses malloc and realloc for widest portability

In the malloc compilation path, it attempts to emulate mmap's ability to make an ANONYMOUS mapping or to associate the memory with a file on disk that is synchronized with the memory. This *almost* supports this extra intended features:

  extra memory file dumper/validator utility for analyzing failures and bug-reports

  memory-image caching to factor-out the loading and reading of init.ps and friends (quick-launch)


So it would simplify the code to remove the file-backing iff we're willing to give up on these other features. OTOH there are at least 3 big steps in the way of achieving them.

  Operator Table is in global Memory File. This means there are function pointers in there. http://stackoverflow.com/questions/18040735/will-statically-linked-functions-have-the-same-pointer-values-across-runs-on-the

  Memory Tables for the Memory File are now outside of the memory in a separate malloc'd area. So the memory is not self-contained anymore.

  The itpdata structure which holds the associations between memories and contexts is also outside of the memory.

And of course the dumper/validator program is not written. It would depend on the details of these other issues.


Another problem is we now have 2 distinct things both called "memory file". One that is primarily memory but with a file behind; and the other I'm now writing which is primarily a file but with a string behind.

The solution I've chosen here, not completely satisfactory, is to name the new string-backed file Xpost_MemFile, like Xpost_DiskFile which is the other subclass or implementation of the abstract Xpost_File virtual class or interface.


Vincent Torri

unread,
Nov 28, 2016, 12:31:41 AM11/28/16
to luserdroog, xpost-discuss
About a quicklaunch, why not having something like LibreOffice (which
has a "quickstarter") : an application which is launch when the
computer boots and does all the necessary initialisation

We can communicate with it via an IPC mechanism, maybe

Vincent
> --
> You received this message because you are subscribed to the Google Groups
> "xpost-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to xpost-discus...@googlegroups.com.
> Visit this group at https://groups.google.com/group/xpost-discuss.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/xpost-discuss/9e5261cc-c693-43ba-873d-ed1d4914e312%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

luserdroog

unread,
Nov 28, 2016, 9:54:38 PM11/28/16
to xpost-discuss, luser...@gmail.com
That's interesting, but I'm a little afraid of IPC, especially cross-platform. And even this approach would benefit from worrying about encapsulating and serializing the memory and other "state".

For the operator table, it could be a static struct instead of all function calls. That would get the function-pointers out of the memory. 
Reply all
Reply to author
Forward
0 new messages