On 14 July 2013 15:49, Marin Ramesa <[email protected]> wrote: > On 13.07.2013 14:53:10, Jiří Zárevúcky wrote: > > So, basically, you want the calling thread to block until the target > > thread terminates. Then the calling thread cleans up the terminated > > thread's resources (if applicable) and returns its exit value (if > > present). Note that some/most API's provide also a detach() function, > > which says that no other thread will call join on the calling one. > > Normally, joining a terminated thread is required to avoid memory > > leaks. > > Thanks. I was hoping to get such a good answer. > > I have read the relevant kernel code and found out that the kernel > already contains everything needed to implement the new system call; it > even includes a thread_join macro.
I am not too much familiar with the kernel, but I don't think it can be this easy. There can be a wide variety of problems, the thread_join() macro is probably not even written with userspace in mind. Also, your "test" makes it painfully obvious you didn't understand what the join() actually does. A correct implementation of join would either fail or deadlock in this code, because the calling and target threads are the same. Well, I don't mean to discourage you, but you should pick something unrelated to threads to begin with. Threads and parallelism are about the least intuitive thing you can find in userspace, so I suspect in-kernel implementation of those is not much better. You could probably get a better introduction to microkernel systems by tinkering with what makes them different from monoliths -- userspace servers. Most of the machinery in HelenOS runs as separate programs, outside the kernel. This includes all of the file system support, most device drivers, support services, etc. It's a much easier start than diving directly into the hearth of the system. -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
