beyond infinity wrote:
cool stuff
)
I like it. It advances more and more.
)
btw: how are you doing it: you assign a port a name and the other process wanting to use the port just needs to get the name - either via command line argument (fork/execve) - and retrieves the actual port number with a lookup system call? say "openport("gui_port");"? which returns the port number, which you use to "dispatch(port_nr,&message);"?
What is planned:
- the parent will automatically have a "default port" which the child can retrieve with a method on the "process" resource (eg Process::GetParentDefaultPort())
- the execution environment can indeed allow process to give names to ports and resolve port ID from a name.
What is hacked at the moment:
- both parent and process use a kernel-scoped variable which keeps the ID of the port created by the parent and requested by the child
send() and recv() messages are then using the port ID.
Are the ports connected to processes(allocated in the tcb) or stand alone so that each process can attach to any public port or probe any public port for messages? Or two processes can share one private port?
Ports are kept appart from TCBs, but when a thread creates a new port (eg. allocates a port ID), it becomes the "owner" of that port. There's no such thing like a "public port" so far. It could be added but only in the sense "a process gets owner of the public port, use it for message reception and then make it public again". Having multiple readers on one port is not part of the design.
(me starts to be unhappy with the current events solution - it is simply unneccessary overhead to redirect flow of control to an eventhandler if a wakeup does the same thing ... *grmpf* I've just thought it might be handy for async events where you have the possibility to register a handler --- you load a file and stroll off to do something else until the server triggers the event ... head in the clouds, that is)
i had the same problem with my event system. It just proved to be overly complicated and useless ... Finally the idea for asynchronous signals will be a single "exception handler point" where the kernel can send the user process: additionnal info about why the user process has been teleported here will then be available ... in a port
) but that was plain silly to start coding it before we have the message passing to deliver keys to the program that required them, don't you think ?