Thinking about it, package is probably better called module so it does not conflict with the meaning of Java's package.


Next thing to do is to start the IPC that the launcher will use to control the kernel. Then following that is starting the actual launcher. Then once the launcher is started, it will then start the main program if one was requested.


The process and thread list would likely best be an ArrayList so that when processes or threads are looked up by their ID, they can used a binary search instead of a linear search.


I must disallow thread and process IDs of zero.


Each process can have its own KernelIPCAlternative. This would simplify the implementation and would also remove the need to have a single lock for every socket that exists. This way when there are many threads communicating with each other, they do not have to block each other.


When it comes to the sockets, they can be shared between different alternatives. So for example when one alternative connects to another, they both just have a single KernelIPCSocket which they share for communication between each other. One issue however are the socket ID numbers, they would need to handle having multiple IDs depending if they are the client or the server. However, technically the socket IDs are only needed with cross communication. There are also 2 billion socket IDs available. For simplicity the client and server can share the same socket ID. However, each side needs its own receive and send buffers anyway. Also sharing IDs could cause confusion when it comes to the side which is receiving its data. So as a rule, the sockets cannot have the same handle number used on the client or server.


Then the server itself for server sockets and just use a new KernelIPCServer since servers do not have any send or receive logic at all. Then I need an interface which will handle the client and server handles.


Actually the connected socket does not even need to know if its a client or server, it just needs to know if it is primary or secondary socket.


Thinking about it, having primary and secondary IDs for sockets could be a bit confusing. I could limit the total number of sockets to 32,768 although that would be a bit bad. It would just be simpler for the client sockets to instead use a single identifier.


Having the primary and secondary identifiers would also complicate things when processes are removed as there would be a shared set of handles which can cause issues if lots of sockets are created.


Also, duplicating the identifier generation code for the third time, so it becomes a class now.


An idea to have so that socket read operations do not block forever, would be to have a sleep in them for the amount of time left for reading, but when data is received there could be an interrupt of sleep performed. However, this would affect everything that sleeps even when it is not waiting on the data. Alternatively the best choice would be to always return immediately. In general most users and myself would want non-blocking sockets for IPC since that is in the general case faster, although the locks can be a bit spinny.


Actually what I can do is after a server socket is connected, the server can be closed. If the clients remain connected without being closed when the server closes means that I only have to accept once and not have a accept closing means. If a client connects and the server closes the socket before a connect happens then the connection would just fail. Also for clearing I will need a not a socket kind of thing to occur. Alternatively if a socket does not exist the returned error code could be connection refused or just connection closed. So if the user-space tries a raw socket read of a random socket number it will just report it as closed. The only issue with this is that the client could open 2 billion sockets, close a very early one which is then reused on overflow. To the kernel this should have no effect, but to the running userspace program things could get weird.


So the question is now, how do I want to handle setting up the interpreter so that processes and then threads can be created for execution? Each created instance of the interpreter should act as its own process since each process needs to be garbage collected and such. There also has to be hooks to the kernel potentially so that garbage collection can be performed and such. However, there is one major difference between the standard interpreter and the rerecording one. The standard interpreter can just use the host garbage collector and references for the most part. The rerecording one will have to keep the objects ordered and have garbage collection performed at known locations such as when System.gc() is called or when memory is expired. I would suppose there would be two kinds of garbage collection. System.gc() would only touch objects which have no references to them at all, but will keep WeakReference. A full one could remove WeakReferencees also. However this may complicate things so it might be best to just have a single garbage collector. This GC would be stop everything since it makes sense. The GC could affect all objects within the execution engine. So then the kernel class which is currently just Object for the execution engine should be an interface instead which has stuff such as garbage collection.


I have this idea to write simulators to test the system. Another idea I have is writing hypervisors so native code can be run. I could have for example a virtual machine of sorts running. I do wonder though about the Nintendo 64. Since it uses MIPS and that is Pompek and Goldberg capable (it should be anyway) it might be possible to do synchronized online multiplayer N64 gaming.


The 64Drive allows write access to the cartridge ROM, the 64Drive is also 64MiB in size. So this means that any unused ROM area could be used as extra RAM.


The month is almost over. I will have to do a synopsis of what has been done over this current month. The past week or more I have been getting in more commits. I suppose a better sleep cycle works wonders when programming. I still do not have an interpreter yet however. But with the multiple refactors the code is far cleaner than what it would have been. It would also work much better compared to before. So generally there has been a great improvement. I did implement manifests and PNG support however. But the major thing that occured was that the code is now much cleaner and much better.