Thanks for your replies!
OSwhatever wrote:
Another thing is that I don't find client-server and point-to-point to be a contradiction. It's a matter to find a service and then you can assign a point-to-point communication for the service in question, like with a TCP connection. You just mentioned two ways to implement it or am I misunderstanding this?
I agree. As I see now, the client-server model could also be implemented with a point-to-point structure. Maybe I should have called the two alternatives as point-to-point and multipoint-to-point.
I have read a bit about L4. It seems that the endpoints it uses are thread identifiers, so I think it is "multipoint-to-point", as several threads can send messages to a given thread.
In my design, the processes have client endpoint descriptors and server endpoint descriptors, which are numbers ("ints" or "longs") in userspace, but in kernelspace they have some corresponding data structure for storing the state (flags, queues, etc.) of each one. Each thread can listen to a server endpoint, or to a group of them.
About fork(): at the moment I think I can implement something similar to UNIX/POSIX, as after a process does fork(), the child process has the same client descriptors as the parent, so if the process had some open file (represented in its side by a client descriptor), then parent and child would end up sharing the same server endpoint, so they would share the open file and its offset, etc., as UNIX does.
The problem I am seeing now is that as each process' fd (file descriptor) is a client descriptor, and each client descriptor points to a server structure, I need a server structure for each open file. So if each process has 1024 open files, and there are 1024 processes, then the file server or servers would total 1024*1024 server structures (assuming there are no shared ones like the ones inherited by fork()). And the server structures are about 96 bytes each, so I am thinking about reducing memory consumption.