Hey, last week hasn't been so productive, as I tried to solve some issues which I do not have to solve because they are being implemented in another way (e.g. I implemented a protocol to be able to ask for a connection which is then being cloned. But I only had to make cloning a connection accessible for Genode). But after meeting with Stefan on Thursday I think that I am back on track. Aside from the problems I managed to solve last weeks problem with the manager thread for incoming ipc connections. So for this week I plan to implement the marshaling of capabilities (sending cloned connections via the Genode interface) and push forward the implementation of the ipc manager. To be able to do this I will have to implement the threads abstraction, since I want to move the callqueue, which is currently implemented in the ipc manager, to every single worker thread. This is because the queue has to be locked for every operation that is performed with it, so having a single global call queue is not that good because of potentially high amount of threads which are waiting to get the lock and therefore currently blocking each other. Furthermore locks (using compare&exchange) and mutexes (using futex related syscalls) have to be implemented to even be able to lock something ;) Additionally I will have to cope with the question how to distinguish between ipc calls which are aactual request and ipc calls which are replies to a previously send call (for asynchronous send calls). The best way would probably be to send an argument which represents a "referenced callid" with every call. It would be the actual callid from the referenced call when the call itself is an answer, and otherwise be zero. Another way could be to generate a hash which is used to identify a single "conversation" (maybe even incrementing the hash by 1 for every answer) and send this hash as an argument with every call. I would be thankfull for any thoughts and ideas.
Regards, Tobias
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
