07:36
So to write the kernel IPC system so that processes may communicate to each other.
10:19
I do wonder if I should have a lock on the security checks or have them within locking regions. This way if threads or the kernel are modifying permissions while one is being checked, it does not get messed up.
10:30
The KIOSocket code can use ReferenceQueue and WeakReference to make it so
the sockets can be cleared away when they are garbage collected and such.
10:31
This means that the socket will need a kind of data point. Although alternatively since everything is garbage collected and managed by the JVM, I do not have to close a socket. If a process runs out of threads (which is a known event) then all sockets can automatically be closed and removed. So when a process detects that no more threads are running (from the main loop) it can perform a cleanup and close connections of other ends and such before it goes completely away. Then I can have a flag to indicate that a process is no longer around and all access to it throws an exception.
11:23
When it comes to the UIDisplayManager implementation on the server, I can have a control scheme set of flags. For example, some interfaces could be running on game consoles without a keyboard, so they would provide a joystick based interface. This would then be a hint to the standard display manager that inputing keyboard keys and such would be impossible. So as an alternative it can pop up a keyboard (and create a virtual keyboard if there is no native one) which can generate the required keyboard events.
11:40
With the launcher using the IPC via the display manager, this means there could be an alternative launcher selection possibly.
11:51
Actually for sockets, I do not have to use the garbage collector, but I do have to close the sockets when the process completes.
13:59
Having reusable (and thus immutable) datagrams would complicate socket communication. Reusing packets could get ugly since old state may be able to creep in.
14:02
When clients connect, they should have their connection accepted so that communication back to them can be performed. It would be similar to TCP in way except with datagrams. Also if I do not have multicasting and do purely two ends of a pipe for communication with accepting, that would make things a bit easier to implement.
15:27
For IPO, I should have it as a kind of mailbox kind of system where. Or instead
of KernelProcess IPOs, the IPCs can store an object to be shared between the
remote end such as an array which then acts as shared memory across two
processes. This personally would be best for if graphics are done and they
need to be very fast, otherwise sending a frame that was drawn across the
IPC would really slow it down.
15:38
Having loops and such with explicit timers is going to very polled which would result in high CPU usage or a laggy interface. Using monitors I can just have special event objects which are given to sockets for example. When an event object is triggered there is either a socket to accept or data to be read.
17:39
I need to wrap the threads created for processes so I know when the threads
go away so they can be cleared so to speak. Alternatively I can make a kind of
debug manager so to speak which can be given events about what happens and
such. Basically something that would act like strace.
20:16
Thinking about it, having the launcher use the IPC interface, although it would be good for setting it up, would complicate things a bit. The launcher runs in the kernel space anyway so it can have direct access to the launcher display manager anyway. It would be faster for the launcher to directly use it anyway. However, when it comes time to actually run programs and such where they have to interact with a UI, they can use the existing IPC for the client and server as I write it. One bonus to this besides the speed, would be that I would have a working display manager interface which I can attach a protocol onto it later, rather than designing the UI layer and the protocol at the same time. Although I have a general idea of the kind of protocol it would be, it would best be done if it were actually implemented first.
20:34
Actually the base display manager should be able to manage and garbage
collect automatically in a way, the UI elements and such if they ever lose
references. Externally, the interfaces would be acted upon by UIDisplays and
such while internally classes would extend InternalUIFoo. The internal
classes would also be abstract classes, because they would need to detect and
have a cleanup method (which is like finalization). This also means that the
UIDisplay which is used by the programs such as the launcher do not have to
worry much about cleaning up internal objects and such. A window might
disappear if it gets garbage collected if a program no longer touches it an
such. Also, say if the internal UI does not support something, it can be
wrapped on by the UIDisplay and such to provide the functionality without
requiring every single internal display to be given such a feature. So in
essence, I can extend the UIDisplay and have basic wrappers for specific
functionality if it is lacking internally. Then this means that if the display
is very primitive and the internal display does not have much functionality,
it will all be virtualized by the wrapper.