![]() | |||||||||||||
Messages in this thread |
Dave Wragg writes: > alan@lxorguk.ukuu.org.uk (Alan Cox) writes: >>> Both of these problem could be neatly solved if the kernel >>> knew that thread-like processes live in teams. There are other >> >> Sort of a thread group like process group model. You need to do that >> cleanly however to keep it fast and Linus happy. > > Last night I added a small amount of kernel support, so that I can > modify LinuxThreads for direct thread creation and find out what the > improvements to pthread_create might actually be. > > A CLONE_MINOR flag to clone creates a /minor process/. When a minor > process clones/forks a new process, the parent of the new process is > the parent of the minor process, rather than the minor process > itself. So by using CLONE_MINOR, all the threads become child > processes of the initial process. You are doing two things with one flag: 1. Allow child to create siblings. (child is a minor process) 2. Actual sibling creation. Perhaps it ought to be split into two flags, so that the parent can itself be a minor process. > should be easier than making CLONE_PID work properly, which would > require the same sorts of changes plus adding thread IDs and some new > syscalls). Maybe CLONE_PID ought to be your CLONE_MINOR. It would be very good to kill the current CLONE_PID, since /proc can not handle it. Let's think of /proc as having thread ID directories, not process ID directories. The process ID is equal to the thread ID of the manager thread. We just need a way to tell procps that not all threads in /proc are manager threads, perhaps with /proc/$TID/threads files. I think CLONE_PID doesn't look so impossible if you redefine the contents of /proc as thread directories. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu | ||||||||||||
| Last update: 2005-03-22 12:43 [W:0.146 / U:0.150 seconds] ©2003-2008 Jasper Spaans | |||||||||||||