Hi everyone,

since I missed the last weekly report due to some heavy learning for my
very last exam on last Wednesday (Stefan knew about, but i missed to inform
you about that, sorry) I will try to cover all aspects of my work of the
last 2 weeks.
Overall in those two weeks I achieved:
- Improving on the connection attributes (where and how they are stored).
This required moving all private attributes from the class
Native_capability to protected, in order to be able to set them new in
derived classes (especially Ipc_istream).
- Make connection cloning available and adding it to the ipc_pingpong test.
(thanks again Jakub for taking the time and explaining this in detail on
IRC)
- Send the destionation thread id with every ipc call. (is supposed to be
set as argument 2 of the syscall)
- Encapsulate ipc calls into an own class for easy handling and information
retrieval (see the class Ipc_call)
- Add timer calls so threads can be send to sleep for a certain amount of
time. Short question: What is the difference between the functions
usleep(useconds_t) and udelay(useconds_t) in
HelenOS/uspace/lib/c/generic/timer.c ?
- Add the implementation of a manager thread for incoming ipc calls (see
Ipc_manager_thread). The idea is to have one object per tasks which can be
asked from every thread whether there is an incoming call for this special
thread. The manager thread itself is started when the first thread is
looking for an incoming call (so tasks not using any incoming ipc won't
have this specific thread). The new thread is only for looking up the
answerbox for incoming calls and storing them in the private call queue of
the Ipc_manager_thread class. When a worker thread is asking the
Ipc_manager_thread for incoming calls, it looks up it's call queue for
calls specified for the asking thread. If there is more than one call
addressed to one and the same thread pending in the call queue, those calls
will be delivered to the thread in the same order as the dropped into the
answerbox (thread specific FiFo). Asking for calls and the delivery of
calls are thereby executed in the context of the asking thread (I must
admit the name "Ipc_manager_thread" is a bit misleading since this object
is not only used by the manager thread but also by the worker threads. I
will chance this with the next commit). Sadly this implementation is not
working yet. Looking up any private attribute in the Ipc_call_queue from
the actual manager thread (the one thread accessing the answerbox and
filling all incoming calls into the call queue) is currently resulting in a
page fault. There are two possible solutions to this: 1) patch gdb with the
description [1] and then attach it to the running qemu which has been
started with the -s argument. Then analyse and fix the problem; 2) code
around this problem: declare a static function in the ipc.cc file, which
holds the ipc manager and is used from the worker threads to retrieve ipc
call from the ipc manager. The ipc manager would then run entirely in a
separate thread.   The second approach would avoid the current problem
completely and I think would be the faster one. On the other hand the
current problem would not be investigated further and (assuming it is not
my fault, the page fault occures) could lead to more problems in the
upcoming development (e.g. if this is due to some wrong address space
handling in the kernel).
So in the next days I will try to fix this issue and finish the ipc
portation (which then should be done quite fast). Sadly I possibly won't be
able to reach my goal for the midterm evaluation, where the schedule
suggests the ipc portation to be finished kind of today. Nevertheless I
will try to cope with the problem as fast as possible so I won't be trown
too badly off my schedule.

If you have any questions or ideas / thoughts please let me know.

Regards,
Tobias
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Reply via email to