Date: Fri, 3 May 2002 09:26:24 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_fork.c Message-ID: <Pine.BSF.4.21.0205030907170.82741-100000@InterJet.elischer.org> In-Reply-To: <XFMail.20020503113516.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 May 2002, John Baldwin wrote: > > Hmm, one thing I'm assuming in some places is that exec() will _require_ a > non-KSE process. I.e., if you want to do an exec() from a KSE process, first > fork() a new process w/o threads and then let it do the exec(). At least, > this is what we sort of agreed to back when you, Peter, and I met and talked > about the scheduler several months ago. > Actually I haven't coded exec yet except to add a funnel. I've tried to code fork so that I haven't precluded the possibility of a forked threaded process actually forking all the threads as well, though in the plan only the 'forking' thread will survive. Why might someone want to do this in the future? It turns out that the housekeeping you have to do if you only duplicate a single thread is as bad as letting the threads all be duplicated if you want to do anything except immediatly exec(). WHile this is not important now, it may be so at some time in the future and I don't want to preclude it. The method I am investigating is to make all the other threads (in syscalls) in the child process report back to the UTS as if the syscall failed.. (or at least EAGAIN). They have no context.. (that stays with the parent) so all that needs to be done is to write out a 'failed' status for each of them before restarting the child thread/process. They don't need to actually be run in any way under the child. Just write out the status block for each one, so that the UTS can correctly reap them. This may seem like a lot of work, but it allows the UTS to recover itself gracefully in the case of a forked process, and allows us to tie up loose ends in the kernel too. It's really not a lot of work. If we just 'never duplicate' the threads (actually the planned course) then it's simple from the kernel point of view, but the process itself may be in such a twisted state that it may not even be able to get as far as the next op (the exec()). Also, it is conceivable that there may be libraries that use threads without the knowledge of the main program. allowijng those libraries to recover in the child may someday be important. I have not coded this but I'm doing everything I can in the design to not preclude it.. The threaded library is in fact the important one.. If I have a threaded bind library or X11-library, and I want to fork. Do I need to know if the bind or X11 is threaded? I shouldn't have to.. I should just be able to fork.. I am not coding for this now but I'd LIKE to be able to code this option in the future and so I am considering the ramifications now.. > -- > > John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0205030907170.82741-100000>