In a View of a Software Project as a Tree-Like Structure: Towards Memory Locking and Memory Access Control in Common Lisp Programs

On beginning a study of National Instruments' LabVIEW programming platform, last year -- that, as was contingent on being a student of a sort of vocationally-focused introductory program in computing, networking, and the electrical sciences, a program hosted by a certain online university -- the author if this article has begun studying a broader concept of data flow programming. Contingent with that study -- not as if try to trump-up any competition towards National Instruments (NI) but rather towards a broader academic study of data flow programming -- the author has been developing an expression of a concept of data flow programming, in Common Lisp.

The author would gladly make reference to the source-tree for that item, here, but it may not be in any useful state for applications, presently. The author has been referring to the project as eSym -- as to denote something towards a concept combining of component concept of symbolic logic and a metaphor with regards to electrical current flow.


While developing eSym, the author has discovered a number of complimentary concerns that may be addressed in a Common Lisp program. Those concerns may be addressed before eSym would be any further developed.

The following article presents an outline of those initial concerns, then proceeds to develop some concepts as with regards to a sense of a broader context in development software programs in Common Lisp.

• An extension may be defined onto the Common Lisp Object System (CLOS) -- at the least, in implementations applying of the Metaobject Protocol (MOP) -- such that the extension would allow for a thread-local modal locking procedure -- and more specifically, a read/write locking procedure -- onto slot values of a Common Lisp standard object.
• This, in turn, may be implemented onto a portable interface for modal locking, such that may be developed directly onto Bordeaux Threads (BT), in a platform-agnostic model
• In parallel to developing a modal locking layer onto Bordeaux Threads, an additional portability interface may be developed onto so many implementation-specific timer interfaces
• ....such that may then be applied in a revised `BT:WITH-LOCK` then allowing a blocking keyword argument -- the behaviors of which would be fully described in the documentation, but in summary of which: 
• blocking t : block indefinitely to acquire lock
• blocking nil : do not block. Rather than returning nil, should signal error of type lock-held if lock is held, such that the calling function could then handle appropriately without storing a return-value from the failed lock acquisition request
• blocking {integer} : block for a duration specified by {integer}, and if timeout, then signal error of type timeout-exceeded
• ....and that may then also be applied in a new `WITH-MODAL-LOCK` macro, as well as underlying `ACQUIRE-MODAL-LOCK` function
• Alternate to Bordeaux Threads:
• Threading in cl-async [github]
• Extended with a BT-like interface in Green Threads
• CPS: Continuation Passing Style [multscheme]
• In operating systems applying a pthreads threading model, this may provide an interface onto an underlying PThread implementations, as via cl-libevent2 and transitively, libevent
• libevent provides a platform-agnostic model for development of asynchronous programs onto C
• As far as a portable timers implementation in recent revisions of cl-async : See also  delay / with-delay (?)
• The data flow programming language, in its abstract graphical representation, could be implemented as an extension of the abstract graphical syntax and the underlying semantics of the Systems Modeling Language (SysML) ... as SysML being implemented with a metamodel extending of the meta-metamodel defined of the Metobject Framework (MOF).
• Alternately, a SysML view for the data flow programming language's data flow graphs could be added later.
• This may extend, indirectly, of de.setf.xml -- with de.setf.xml providing an interface for parsing the XMI schema and the XMI schema then serving to present a structured interface for processing and I/O onto metamodels serialized onto the standard MOF/XMI binding , with any number of vendor-specific conventions in the same.
• An implementation of the Object Constraint Language (OCL) should be developed as part of the same -- such that may apply the ATN parser, such that is applied in de.setf.xml -- the parser implementation in the OCL implementation therefore remaining aligned with the XML implementation
• This data flow programming model may  of course be implemented with extensions onto McCLIM, for managing interactions with a data flow programming graph, as via a CLIM application frame.

In parallel to the matter of thread-local slot value locking: While I was developing some notes as with regards to a lock ticket caching framework -- and a more generic object buffering framework -- as to address a question of how a program may provide an interface for controlling access to the slots of  buffered object, such that the buffered objectwould be simultaneously accessible in a buffer cache and from there, accessible in any number of threads of a program, as well as being accessible broadly in the data space of the containing process -- I had developed a question as to how and whether it may be possible to control access to a region of memory. In regards to how that may be approached in software programs developed on the Linux kernel, my question -- as such -- was promptly answered, on discovering the shmget(2) and shmctl(2) manual pages, as well as the useful  shm_overview(7) such that provides an overview of an independent SHM interface providing file descriptors for shared memory segments.  I would denote some additional caveats to this matter, as well:

• The  shmctl(2) manual page, specifically, describes some of the structural qualities of the following structure types in the Linux programming environment:
• The C structure type shmid_ds 
• Application: This type appears to be used for providing information about the Kernel's implementation of the SHM interface. For instance, there are some structure slots for recording of times and process IDs (PIDs), within the shmid_ds structure type
• The shm_perm slot provides further structure, as denote in the following
• The C structure type ipc_perm
• This type uses the key value as applied also with shmget(2)
• This type also provides a record for UID and GID values as well as flags for access permissions defined onto a shared memory segment
• Consequent to a further study of the shmctl(2) manual page, it may seem that the shmctl() function is defined for purpose of reflection onto system-wide registers with regards to shared memory allocation
• An orthogonal question: Onto what platforms other than Linux is the Linux SHM interface considered portable?
• BSD?
• QNX?
• It's not the same as mlock(2)
• Application: Ideally, there may be a compatibility interface defined between values used in  shmget(2) and similar SHM functions, and values used in mlock(2). Such a compatibility interface may or may not exist, presently, within the body of existing work in free/open source software and systems
• mlock(2) may be applied in at least two manners of usage case
• To prevent a memory segment from being paged to disk, as to ensure that data in the memory segment will not be recorded in any permanent medium, namely towards applications in data security
• To ensure that a segment of memory will not be paged to disk, as towards ensuring a deterministic timing within the calling program, for access onto the same segment of memory -- as towards applications in a realtime operating system (RTOS) environment, such as for embedded computing. As a further reference, to that effect: sched_setscheduler(2)

This outline, of course, does not present a full interface onto SHM in Linux, for any single Common Lisp implementation. The previous outline may serve to develop some further knowledge, towards some questions with regards to memory management, within any single Common Lisp implementation, viz a viz:

• One  "first question", as towards the origins the previous outline -- more broadly, as towards preventing unwanted access to regions in a program's data space -- in that regards, towards a design for data security within Common Lisp programs. 
• The question, in short: How can an interface be developed for controlling access to memory registers within a program's data space, in a Common Lisp program on any single operating system platform? 
• Nothing to compete with the Java programming model, certainly, though Java also defines some controls for data access, at least insofar as with regards to definitions of Java fields and Java methods in Java classes. The author is not presently aware of any similar SHM interfaces in Java.
• A second question, as contingent around the matter of RTOS applications: 
• The question, in short: How can memory be locked, within a Common Lisp program -- whether permanently or temporarily -- as to not be shifted in the data space, within garbage collection processes?
• This is orthogonal to the question: How can memory be locked, within a Common Lisp program, as to not be paged out to the system's page area?
• The "second question" is notably a naive question, it demonstrating some assumptions as to what side effects a garbage collection (GC) process may produce, within a Common Lisp program. Namely, there is an assumption that an object's object address may change within the duration of a Common Lisp program -- assuming that an object in a Common Lisp program may not be left where originally created within a program's data space, after completion of any single GC iteration.
• Of course there would be some orthogonal concerns, and perhaps some orthogonal design concepts, for instance:
• Is it possible to define a specific region of memory as being locked with mlock(2), and such that that region of memory may be used for allocating multiple Lisp objects? 
• May that serve to provide a methodology for implementing a non-paged memory IO region wtihin a Common Lisp program?
• May it serve to allow for a tunable efficiency in applications, such that mlock(2) may not need to be applied at every time when a new Lisp object is allocated? 
• If a shared memory control interface would implemented, in parallel to this feature, of course the shared memory control interface may produce some side effects as with regards to this feature's implementation -- for instance, in that an access-controlled region of memory may be effectively contained within the mlock'd memory region.
• There may be some additional concerns addressed, as with regards to manual memory management in Common Lisp programs, for instance:
•  That  if there may be an application in which one cannot simply cons and forget and leave the garbage collector to clean up the memory space for unused objects
• ...then as well as the implicit memory allocation of creating a new Lisp object
• ...a Lisp program may provide an interface for manual memory deallocation, thus towards both
• obviating the burdens for the garbage collector and also 
• allowing for a deterministic procedure chain, insofar as for memory management within a Common Lisp program
• This can be implemented with requirement for multithreading.
• An explicit memory deallocation thread may be implemented
• ...as to be coordinated in scheduling alongisde the garbage collector
• ...such that it would be accompanied with rigorous definitions of memory deallocation forms, for ensuring that objects created for "one time use" within a single lexical environment will be explicitly marked as to deallocate when control exits from within the same lexical environment.
• ...though that would require a storage of a separate "to-deallocate table" essentially separate to reference-counted memory -- lazy references? -- and a methodology for iterating across the same table, perhaps alternate to a methodology of scanning Lisp objects recursively for count of object references and recursively deallocating those denoted only as "not referenced".
• ...and may be applied with an functional interface, parallel to cl:gc, rather such as foo-mem:prune
• ...such that an application applying the memory prune function may be exist in parallel to applications not doing such explicit memory deallocation.
• ...and should be accompanied with a conditions model, such as for when   foo-mem:prune would be applied on any object that would contain, as an n-ary  referenced object, any object that would be known as that it cannot be pruned, for instance any definition of a class defined in the cl package
• ...and must also be accompanied with a lengthy description of how foo-mem:prune would function on individual objects to be pruned
• Note: Reference vs definition -- for instance, that a reference to a string is not a string object itself
• Essentially, this may serve to develop a concept: Memory management for objects referenced within only a single lexical environment
• Ideally, this should be implemented as to not entail any overhead for "Reference counting".

Certainly, a Common Lisp interface on the SHM features of the Linux kernel may be implemented as a layer onto an interface onto mlock(2) -- and so, the development of the mlock(2) interface could effectively precede the development of the SHM memory control interface. Also clearly, such extrnsions would need to be implemented in all of an implementation-specific manner, as onto the memory management features of any single Common Lisp implementation. This, then, would certainly require much of a detailed study onto those same features, and perhaps an application of the C programming language.

Some further notes in documentation should be forthcoming, to that effect, as may be published in this web log, henceforward. The author proposes to limit the study onto two Common Lisp implementations specifically:

• Steel Bank Common Lisp (SBCL)
• Clozure Common Lisp (CCL)

...at such future time as when it may be immediately feasible as to address the following procedural outline into an implementation:

1. To begin such a study of memory management, on those platforms.
• Ostensibly, to develop a series of SysML models for describing the conventions applied in memory management on those platforms
• UML class diagrams for illustrating structures and relations of explicit and inferred data types (e.g. VOPs in CMUCL and SBCL)
• SysML block diagrams for developing a block/port-oriented view of memory and memory management  in the respective Common Lisp implementation
• Onto CCL, block diagrams illustrating of qualities of the FFI interface
• State Charts in SysML for describing memory management in terms of finite state automota
2. To develop an interface for an  mlock(2) locked region of memory in a program's data space
3. Implicitly: To develop a Common Lisp interface onto an operating system's underlying authentication and authorization (A2) model
• To furthermore extend that interface onto the A2 procedures of Kerberos 
4. To develop an interface for an SHM controlled access to memory within a program's data sapce
• To develop such condition types, deubugger features, and other features unto the Common Lisp semantics, such that may serve to simply the programmer's view of the memory access control forms 

If the reader may wish to inquire as to why those two platforms are specified, in this article:

• Both of those platforms may be applied on an ARM microprocessor architecture
• ARM, in turn, is applied within a number of embedded computing platforms, including mobile phones
• Although there are additional Common Lisp implementations available for the ARM architecture -- including ECL -- it may be feasible to limit the study to, essentially: 
• One implementation of or deriving from CMUCL, as with SBCL at the original "Point of fork"
• This should be approached with an observation about signals, interrupts, and foreign threads in SBCL -- as denoted as being problematic for an interface onto a Java Virtual Machine, at the web site for CL+J 
• This should be approached, also, with an observation as with regards to the newer thruption model in SBCL, and related features defined in recent editions of SBCL
• One implementation deriving its implementation more broadly from LibC, as with CCL and its own respective foreign functions interface
• This may be approached with consideration: 
• That the Linux Kernel is implemented in C
• That the fundamental interfaces to the Linux Kernel are provided as for C programs
• That the FFI model developed in CCL may applied in a prototype fork for and towards applying such extended memory management procedures as denoted in the previous outlines in this article

Of course, it would be impractical to assume as if an extension could be addressed instantaneously onto two separate Common Lisp implementations, if only a single developer is developing the same extension. At this point in the article, the author arrives at a point of decision as to which Common Lisp implementation the author would wish to focus on, first, if to develop such an extension. That question, then, may be pushed further down the effective stack, with a couple of corresponding questions:

• How may a mobile application development model be developed in free/open source software, for supporting development of mobile applications and desktop applications with Common Lisp?
• How may CLIM be applied within such a model for mobile application development in a free/open source regards?
• How may that be extended, furthermore, in applications of "new" embedded computing models, such as may apply the BeagleBone Black platform, Gumstix, or any other single-board computing model capable of running a Linux operating system?
• How easily can CCL or SBCL and McCLIM be installed onto an Android device, for purpose of development testing?
• How easy would it be to use the CLIM REPL, in such an installation?
• How many separate concerns may be addressed onto CLIM, as for design of mobile human computer interfaces -- in whatever regards, if as an alternative to conventions developed of popular desktop computing interfaces? 
• How and how well may CLIM be integrated with an on-screen keyboard, as of a tablet PC or a notebook with touschscreen?
• Would it not be useful to include a modeline -- even if it would be a 'hidden modeline' of a kind -- onto every single window created, in such an appliation of CLIM? Then how would the 'meta' key be implemented, for key input to such a modeline?
• How can a commercial interface be developed, onto such work, and it not be limiting towards the free open source nature of the software that would be applied in such work?
• Sidebar: "Free/open source" does not imply "Insecure"
• A deterministic model will not be illustrated for that thesis, in this article
• Sidebar: Incentives?
• Data-secure computing for small/medium enterprise - referencing strongSwan, Kerberos, and JacORB as providing support for Kerberos and SSL onto CORBA
• Games programming for mobile platforms, in Common Lisp? 
• Can we make it look more like Half Life? Should we?
• What about music?
• What about folk music?
• What about educational applications developed albeit with a novel game-like interface but lending towards any actual, fundamental concepts in mathematics, if not also towards the material sciences?
• What wonders may await, in the literary works of Charles Babbage?
• What wonders, in a view providing of an implicit sense of gender neutrality, if not a broader sense of cultural neutrality, with regards to mathematics and science? barring any discussions lending immediately to a maturity of nature.
• Furtherance of concepts in the state of the art?
• IDE development in the heterogenous systems programming environment
• Towards implications for the software development environments in applications of virtualizaiton and software-defined networking (SDN)
• "Because CORBA"
• Beginnings of discussion with regards to community support, if not for further commercial support for Common Lisp  applications on mobile platforms?
•  "There's the kicker"
• Existing services for issue support may include:
• YouTrack
• Bugzilla
• Request Tracker
• GNATS
• Debian BTS
• Bug tracking in Canonical's Launchpad system
• May entail some platform-specific focus about Linux
• The following mobile platforms implement Linux:
• Maemo
• Android
• Fire OS (Kindle Fire)
• Firefox OS
• Chromium OS
• Any single single-board computing platform on which Linux is available
• BeagleBone Black (BBB)
• Can run Android, more specifically. See also: Rowboat
• Raspberry Pi (RPi)
• Gumstix
• Etc.
• RTOS features "To be determined" by platform (TBD)
• Focusing on the Android platform, specifically, there may be an interface available for bug tracking onto any single Anrdoid app store (TBD)
• Questions with regards to tools
• A hypothetical model for capturing results of an application error: Fork, save diagnostic data-optionally save entire Lisp image, and debug on 'Own hardware"
• Revisions for "Other users" : Do not save session-local data within diagnostics; Do not save Lisp image; ensure full authorization and authentication with upstream issue tracking agency, in network transactions transmitting of diagnostic information
• Debugger hook : How to apply that usefully on a mobile platform?
• Usage Case - Developer's mobile platform
• Context: Prototyping and testing
• Context: Unexpected situation in program
• Usage Case - User's mobile platform
• Context: Regular application procedures
• Context: Unexpected situation in program
• Debugger hook   How to apply that  usefully, for server diagnostics?
• Data models : How to "flag" session-local data values, so as to prevent their printing or storage onto media outside of environment of a running Common Lisp program?
• Systems models : How to securely and conveniently (?) encrypt a saved Lisp image?
• Further implications onto design and development of digital platform operating systems?
• How to integrate developer tools, in a novel manner, with Xen? 
• cf. Xen Dom0 
• Emulator as Dom1 instance
• Xen must be (?) installed directly on platform hardware
• Orthogonal to: Microkernel design.
• cf. Amazon Web Services
• Application of Xen

To this point in the article , the article has diverged from the original topic of developing a data flow programming model in Common Lisp.  Figuratively, the eSym project might represent some figurative icing on the figurative concha otherwise described in this article. The majority of such tasks as would entail an extension of interfaces onto the Linux kernel -- as addressed in this article, albeit superficially -- those might be approached albeit without a cup full of sugared bread, but with a substantial portion of documentation regardless.

This article has described a substantial number of individual concepts and related task items, such that may be addressed into development of an essentially arbitrary number of source trees.

This is developed under the MetaCommunity project, towards a further goal of developing a comprehensive architecture for application development in Common Lisp, and an orthogonal goal of reviving the design of MIT CADR for application onto contemporary microprocessor architectures, denoted as the CIIDR project.

Notes onto RTOS Linux

Personally, I'm not one to make any sort of lengthy association between culture and computing. It's my point of view that a computer is a practical thing -- nothing of "style" or of too much of conversation, to me. I also don't talk for long about my car, or my experiences in driving, or my experiences in operating heavy engineering equipment. Those are all practical things, to my point of view. If I might have any sort of a "style" about computing, regardless, I suppose "Tight lipped" would be the label that I would prefer, at that -- "Tight lipped" as contrasted to my sometimes bouts of rambling inconherently, and likewise of writing, though without a great sense of structure.

I understand that as I would continue to pursue a course of formal, academic study in computing and -- correspondingly -- a study in digital electronics, that I should wish to learn to develop a normative style of writing, then -- such that I would not be thought to be inept at communication, at least, though I am inept in much of "Style," I think. It's on the premise of computing being a practical thing, to me, that I endeavor to not be "Self conscious" about writing about computing -- even when I am writing without a great sense of structure or of focus.

If I would begin to write with more of a sense of structure and/or a sense of focus, then, I think it could go well if I was to begin to write about a single, linear process in development. At that, the first thing that comes to mind that I would like to write about: A manner of study, with regards to applications of the Linux kernel in realtime systems on thin client platforms. Of course, that in itself might not be so much of a simple topic to write about. If there is even a single vocabulary to the concept, I have not learned it yet, and if there is single, discrete set of technologies to the applications of such a concept, realtime systems on thin client platforms, I have not found that set of single, discrete technologies, as yet. Candidly, being a student, I have found at least a small assembly of hetereogenous components, some of which share some common qualities -- for instance, that a BeagleBone Black and an Arduino board can both conduct communications using the I2C protocol,  and that the Altera Cyclone III on eSOC FPGA board manfucatured for DeVry University students (a group which I am currently one of)  .... that it has IO headers at least, though he eSOC 3 is currently lacking any kind of a user manual, schematic, or other design documents, and therefore there's not much I can do with it.

In a practical regards, I think that a realtime Linux platform could be of some interest with regards to parallel computing models using single board computers, if not furthermore of Cubesat design -- neither of which would seem to be hot topics in "the consumer market," at this time, however. I'm sure that there could be an app made for news about it -- maybe it could be more popular, then. Certainly, it's a bit more complex than what can be developed on a mobile phone.

In all that complexity, perhaps there are some discrete qualities, however -- such that one may endeavor to "Snapshot," in a manner of writing -- resources, such as:

• Article: Jones, M. Tim. Anatomy of real-time Linux architectures. IBM Developerworks. 2008
•  In a structural view: The article denotes three primary types of Realtime Linux kernel, namely: Thin-kernel; Nano-kernel; Resource kernel. The article also describes the baseline architectures of the Linux 2.4 and Linux 2.6 kernels.
• Project: ADEOS Project
• ADEOS was denoted under the nano-kernel architecture, in the article published by IBM (Jones op. cit.)
•  ADEOS publishes an interesting article, in sort of crossing domains between SMP and cluster computing, namley in a context of a nano-kernel architecture
• Realtime Linux distribution:  Timesys LinuxLink
• This item, in particular, has really "Caught my attention," this week. I denote it, here, as a realtime linux distribution considering that it is an apparent descendant of a Linux distribution denoted in "that IBM article" (Jones op. cit.) namely, Linux/RK, denoted there as a realtime Linux distribution implementing a resource kernel model
• The Linux/RK project page, itself, makes reference to a number of additional resources, describing concepts of the architecture of a resource kernel model as implemented in Linux/RK. (Note that the resources are dated around 2001, and are available in Postscript format, but may be converted to PDF format with some GPL licensed tools such as 'ps2pdf', cf. Cygwin)
• In a practical regards, I've noticed that the Timesys web-based Build Factory provides support for the BeagleBone Black single-board computer and the TI Sitara microcontroller unit used on the BeagleBone platform. I'm well impressed, moreover, to see how well architected the Timesys Build Factory is. I've compiled a single build with it, and have yet to install that to my BeagleBone Black, but I look forward to that -- though catching up on some other  items, in the meanwhile.
• This item, in particular, I think I may be able to incorporate into a senior project. Though the project would be focusing primarily on developing an I2C I/O model using the BeagleBone Black, but with there being a solid baseline OS avaialble -- namely, LinuxLink -- as already catered towards realtime and embedded systems, that substantial bit of existing work could simply help -- by a long shot -- in defining a modular design, in the project.
• For a bit of historical context, there's an article about Timesys' original Linux/RT, at the Linux Journal
• Lazenby, Daniel. TimeSys Linux/RT (Professional Edition). Linux Journal. 2000
• Standard: POSIX 1003.1
• Resource:  Navet, Nicolas. Scheduling under Posix 1003.1b. INRIA. 2005
• Resource: POSIX 1003.1 FAQ. Open Group. 2013

 From there, the snapshot begins to focus more on the development environment, less on the OS itself.

•  Virtualization platform (x86 architectures): Virtualbox
• My having recently begun to develop a Windows 8.1 desktop on an x86 (amd64) PC, such that uses a UEFI architecture in its boot process -- that, adding some distinct complexity for any sort of a "Dual boot" configuration -- and the same PC has an intel graphics card that doesn't work ideally well, on Mint LMDE, "Out of the box", it's therefore my impression that Virtualbox provides a "Nearest to ideal" methodology, then, for both developing software in the Linux environment and continuing with the typically Microsoft Windows-dependent lab materials in the courses at DeVry University Online (DVUO)
• I've installed Linux Mint (LMDE edition 201403) into that Virtualbox image, and have begun to use that desktop as an overlay onto my Microsort Windows 8.1 desktop. 
• Virtualbox provides a nice seamless view mode for graphical applications in compatible Virtualbox virtual guest instances. When Virtualbox is using the seamless mode -- as for displaying GUI applications running directly in the compatible virtual guest instance -- it makes for a relatively smooth integration with the virtual host PC desktop
• There are some limitations -- such as namely:
• That the desktop menu of the virtual guest instance is inaccessible in seamless mode. However, there are some quick hotkeys that Virtualbox provides for changing the view mode, such that allows for access to the desktop men, as in fullscreen view mode.
• That it does somewhat "lag the PC", it being a virtual OS image for an OS that would typically be installed directly onto "Bare metal" hardware
• Those are, effectively, the only limitations I can observe of that configuration
•  Of course, it would also work "Swell" with the build factory image created by the Timesys web-based Build Factory
• Virtualbox can be easily configured to provide "pass through" I/O for USB devices, such as would allow for the BeagleBone to be configured directly via USB from within the Virtualbox virtual guest instance
• With or without an X.org window server running in the Virtualbox virtual guest image, Virtualbox nonetheless provides a framework for a full Linux development environment, without the characteristically "hairy" qualities of the process of installing a second bootable OS diretly onto a PC that uses UEFI.
•  The virtual media device as used by Virtualbox for its machine and block storage device emulation procedures, that media device is essentially contained within a single virtual media image, such that can easily be backed up and/or relocated to another PC.
• Advice: To use Samba and CIFS instead of the Virtualbox "Shared folder", for sharing files between the Virtualbox virtual guest image and the virtual host OS.
• "Some limitations would apply"
• Programming Language: Common Lisp
• This topic necessarily would entail a number of distinct sub-topics, such as at least one topic for each Common Lisp implementation being used in a single Common Lisp development environment. 
• Of course, one cannot simultaneously use every Common Lisp implementation that exists. Personally, I wish to focus on:
• Steel Bank Common Lisp  (SBCL) 
• towards: Defining a "New" Lisp OS
• Focusing on platforms:
• amd64
• armhf (where applicable, else armel)
• See also: Connors, Jim. Is it armhf or armel?. Jim Connors' Web Log. 2013
• Shell command: readelf -A /proc/self/exe | grep Tag_ABI_VFP_args
• NOTE: The distro might be compiled as armel, though the MCU might support armhf features, regardless
• Clozure Common Lisp (CCL)
• towards: A Common Lisp implementation providing close integration of existing software components on the Linux platform -- typically via FFI -- including the Linux Kernel itself
• Concept: MPI
• Resource: ParGCL, another Common Lisp implementation
• Concept: I2C
• Short summary: Standard I/O protocol for digital electronics devices onto a common digital signal bus
• Supported in the two PRU-ICSS modules in the TI Sitara MCU (cf. BeagleBone Black)
• Concept: CORBA
• Short summary: Platform-neutral architecture for remote data procedures and remote procedure calls within heterogenous networks
• Concepts: CORBA GIOP, CORBA IIOP
• Concept: CORBA IDL

 That, then, would effectively serve to complete the "Snapshot," this morning -- the "Snapshot" amended, then, with subsequent updates.

I C SPACE LIGHTS....

 ED. NOTE: I'd cut and pasted this from my own response, tonight, in an online forum.

Considering the OSI seven layer model: There may be some applications possible for existing fiber optic "layer 1" technologies, therein using  a sort of "different" optical media, though, namely in real "Outer space," moreover in a context of the emerging privatization of "Outer space," as around such as Richard Branson's Virgin Galactic and SpaceShip Two, the latter's "home spaceport" being located near Las Cruces, New Mexico.

Observing the web site of the NASA LLCD  project, specifically, NASA has begun to develop technologies such that may be suitable for high-throughput communication between satellites, using a digital encoding on optical signals, in real "outer space." Of course, there would also be some complex satellite positioning algorithms being required, in the same -- the network being absent of an effective "cable" between each of the respective light-signal endpoints -- that the system appears to function in a manner broadly analogous to a hypothetical system of a flashlight (or rather, a laser) and a lens, each in a digital circuit, moreover absent of intervening "air".

If the optical networking technologies used in the LLCD project might be -- in some ways -- analogous to conventional fiber optic media, then, and if the same technologies may be suitably miniaturized, perhaps such a possibility could be recognized commercially, and applied towards further production of that technology. Of course, it might not be viable for a "mass market," but it might be useful for application in further development of some emerging technologies -- such as, ostensibly, towards asteroid mining at orbital lagrange points above low earth orbit. No doubt, such systems as could be used in a by-in-large automated orbital asteroid mining system, those systems could function without continuous optical networking, but certainly it would not be a bad thing if a constant optical network was available as among the respective "mining satellites", and wherever the main "mining control people" would be, whether in orbit or (ostensibly with a repeater between the optical network and a radio network) on the ground.

Conceivably, if it may be possible to build the further OSI layers on top of that optical media, then -- perhaps, as in implementing an existing TCP/IP stack effectively onto such networking media, as could be approached in using Cisco's IOS and its QNX RTOS baseline, or an RTOS Linux implementation -- then, it might even be possible to implement CORBA in real "outer space". Of course, it would also need a suitably resilient digital electronics platform, for such a networking system to function continuously, in orbit.

Maybe one day, there could be CIsco routers in real "outer space."

Notes - Applications for Memory Locking, and a Thesis Outline about Real Time Application Design

While studying some materials with regards to applications for Common Lisp programs, in integration with Amazon Web Services (AWS), I began to read about the process of request signing for the REST API available onto select AWS applications. This morning, I've found the following resources, specifically in that topic domain:

• Signing AWS API Requests
• Note Signature Version 4 
• Observe: List of supported services (ibid.)
• Observe: Request structure for Signature Version 4 (ibid.)
• Corresponding reference: Signing AWS Requests By Using Signature Version 4, represented as a procedure of exactly three tasks
• Deprecated: Authenticating Requests (AWS Signature Version 2)
• The heading, Making Requests, under the S3 Developer Guide
• Observe: Summary about access keys and temporary security credentials (ibid.)
•  AWS Security Credentials
• Pages in subsections serve to provide a more detailed overview of the availability and application of security credentials, in AWS REST API requests, as well as highlighting the relevance of the AWS IAM service, in AWS request authorization (ibid.)
• Observe: Secret key component of an AWS Access Key (heading Types of Security, ibid.)
• What is the AWS Security Token Service?
• Observe: AWS Temporary Security Credentials (ibid.)
• Making Secure Requests to Amazon Web Services
• Observe: Notes about security features provided with SSL (ibid.)
• See also: Horman, Simon. SSL and TLS, An Overview of A Secure Communications Protocol. available
• Observe: Partial list of services supporting AWS request signing (ibid.) The reader may be advised to refer to other normative resources, for more information.
• Observe: Table of official AWS APIs (2008) (ibid.)

In regards to the secret key component, specifically, I thought it was an apropos time to begin studying about memory locking.

In that course of study, I'd found documentation about the POSIX mlock() function, as implemented in GNU LibC on the Linux platform — namely, manual page mlock(2), in the Linux Prorammer's Manual

It was in reading the notes section of that manual page, when I discovered a certain item of some tangential interest, as highlighted in the following excerpt — emphasis and link added, for purpose of clarity and informativeness, respectively, as namely with regards to the matter tangential to this study with regards to signing and authentication of AWS REST API requests.

Memory locking has two main applications: real-time algorithms and high-security data processing. Real-time applications require deterministic timing, and, like scheduling, paging is one major cause of unexpected program execution delays. Real-time applications will usually also switch to a real-time scheduler with sched_setscheduler(2).

— manual page mlock(2), in the Linux Prorammer's Manual

Of course, if in trying to address memory locking, if for purpose of both secure data processing and real-time application design, simultaneously, it might serve to create a sort of priority deadlock. Thus, I arrive — essentially — at the matter of why I've begun writing this notes page, this morning.

Real-time application development — such as I understand — would be a concept rather broader than, specifically, the Common Lisp programming platform.  As a software developer familiar with the Common Lisp programming platform, I may wish to specialize my own point of view about the concept, as though it was a concept of some meaning, as if exclusively with regards to Common Lisp software programming. In that sense, I might like to endeavor to "Brand" the concept, however  — speaking as a student of computer networking, somewhat familiar with some Microsoft products  — I'm afraid that my own specialized "Brand concept" would not be sufficient as to really address the nature of the broader concern, in any sufficiently technical regards.

My logical bias about the concept, thusly denoted, I would like to gather some notes, here, as with regards to design, development, and implementation or real-time applications. It's my point of view that the following observations, broadly, might "stand to reason," so far as one might logically ascertain in a sense of focus, if not of some practical, perhaps by in large personal experience with regards to computer systems and software programming.

Causes of execution delays in software programs

• Execution Delays, in an Event-Oriented View
• Garbage collection (GC)
• Virtual memory paging
• Linear network/communication delays
• I/O blocking
• Causes (TBD)
• Mitigating factors
• I/O Scheduling
• ...
• Network latency
• Link-level latency
• Packet routing
• Schedule Wait
• Event Networks
• Linear dependencies onto other events
• Execution Delays, in a Composite View
• Total momentary delay time 
• As in: The sum of event delay times among individual processes 
• Aside: View of an application as a finite state machine (i.e. FSM)
• Mechanical delay time
• measured as a discrete time value
• the difference of (1) expected time of completion and (2) current time
• The "Butterfly factor"
• Nondeterministic systems
• Unexpected delays
• Mitigating factors:
• Expectations Resilience
• Design Resilience in Systems Planning and Development
• Advice
• Painter, Bob Ross
• Painting Mountains, Bob Ross
• Bob Ross Incorporated
• Proverbs Literally of Patience, a selection of: 
• "Ants aren't a strong species, yet they prepare their food in the summer" — Proverbs 30:25, International Standard Version.
• “Simplicity, patience, compassion. / These three are your greatest treasures. / Simple in actions and thoughts, you return to the source of being. / Patient with both friends and enemies, / you accord with the way things are. / Compassionate toward yourself, / you reconcile all beings in the world.” — Lao Tzu, Tao Te Ching. excerpt.
• Guns 'n Roses, Patience. music video

Commentary (ad hoc)

Of course, if I was to develop a singular thesis about the concept, then I should certainly like to detail each of those technical topics, further. Of course, I should have to elide the subjective/creative/interpretive matter of advice, in that.
  

Candidly: If at this time, I was enrolled in any sort of a formal graduate studies program, academically, then perhaps it might be more obviously relevant to the academic institution to which I am enrolled that I would begin to write a thesis paper. Failing that, however — candidly — I cannot expect to find either guidance or personal incentive, to develop any such outline into a thesis paper. That being, no doubt, a task requiring of no small sense of focus, I shall prefer to leave it at an outline, at this time.