Hi,
Artlav wrote:
Korona wrote:
Shared libraries share the heap with the process they are running in.
But then how would it have an internal state?
I.e. a GUI library should be able to track every process's windows and be aware where to pipe the input to, it can't be perfectly local to a single process.
In my design, a library is it's own thing loaded separately, and all linking happens at runtime.
If a process wants to access library functions, it requests an interface for a specific lib and gets a function table.
Libraries are mostly a (more sophisticated/more complex/more flexible) alternative to "cutting and pasting" source code from a text file of frequently used snippets of code/data directly into the source code of an executable. The library's code becomes part of the executable's code, and the library's data becomes part of the executable's data. They're only separate things until they're linked (and aren't separate pieces after linking, when they're executed).
For your design, to me it sounds like you don't really have libraries but you have something much more like "services" - things with their own independent data and state that don't become part of whichever executable uses it; that communicate via. some sort of IPC (something like remote procedure call in your case, which might even look like a normal function call if the OS uses a "SASOS/Single Address Space" approach and there's no virtual address space switching involved).
A "GUI service" would have internal data (to track every process' windows, figure out where user input gets forwarded, etc) but a GUI library wouldn't. You could have a "GUI library" and a "GUI service" too; where the GUI library could be pure code to make communicating with the GUI service easier, and could also have a process' private data/state that the GUI service doesn't have.
However, what I really think you're trying to do is to merge both concepts (either a service that also has a process's data like a library, or a library that has its own internal data like a service) to create a kind of "libservice". Unless the OS is a SASOS this accidental merging of concepts couldn't have happened (the concepts become incompatible when multiple address spaces are involved and IPC needs to be more than a normal function call).
If my guesses are right; then the solution would be to clearly differentiate between "process data" (for each process using the "libservice") and "service data" that belongs to the "libservice" itself.
In practical terms; for every kmalloc call the kernel tracks which process or which "libservice" got the memory; and a "libservice" would be able to allocate memory for its own internal use (that is not freed when a process is terminated) but would also be able to allocate memory on behalf of a process (that is freed when the process is terminated).
Cheers,
Brendan