Hi Marin,
thanks for your interest in HelenOS, but as Jiri already mentioned,
modifying the implementation of kernel-managed threads was perhaps not
the best choice for your first-time contribution.
It's not that adding the thread join functionality is such a complex
task (it is manageable), but it definitively requires a pretty detailed
knowledge of how the kernel currently works and how it deals with the
threads. A few points to consider:
1. The most important reason (although not the only one) for joining
threads in the first place is to retrieve the return value (status
code, however you want to call it).
Thus introducing the return value to both the kernel and user space
(kernel-managed) thread API is probably a good start. I might commit
some code related to this soon if I find the time to properly test
it -- even after many years of experience meddling with such core
kernel code cannot be described as light-hearted.
2. Also the return value should be perhaps something more versatile
than just an int, perhaps a void *. My suggestion for the prototypes
of the user space libc calls would be:
void thread_exit(void *status);
int thread_join(thread_id_t thread, void **status);
3. Note that thread_id_t is always a 64bit integer. Thus you cannot
just pass it as a plain syscall argument, because it will be
truncated to 32 bits on 32bit platforms. You need to pass a pointer
to the variable to the syscall.
4. Your code of sys_thread_join() won't work as expected simply because
all user space (kernel-managed) threads are currently always created
as detached (see the comment and the first call in the function
uinit() in kernel/generic/src/main/uinit.c).
In any case, please don't be discouraged.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
