Date: Mon, 23 Jan 2006 16:02:01 -0800 From: Julian Elischer <julian@elischer.org> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: kernel thread as real threads.. Message-ID: <43D56E79.60504@elischer.org> In-Reply-To: <20060123232836.M48094@fledge.watson.org> References: <43D05151.5070409@elischer.org> <200601231616.49140.jhb@freebsd.org> <43D55739.80608@elischer.org> <20060123224756.R48094@fledge.watson.org> <43D56468.1060101@elischer.org> <20060123232836.M48094@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Mon, 23 Jan 2006, Julian Elischer wrote: > >> it would be no different from when a threaded process exits now.. >> >> With the current setup you have a whole set of worries about what to >> do about the thread responds when the process has already died. >> These worries are aqctually simplified if the thread is part of the >> process. (at least I believe this to be the case). > > > It would be good to know what the aio specs say (and what real > applications expect) to happen on the current set of "single > threading" events: > > - exec the outstanding operation must be aborted.. the address space it is aimed at is being wiped.. > - fork (although davidxu is changing that) well, the operation woudll continue for the parent only I woudl assume. > (although davidxu is changing that) I'm not convinced that that multiple threads should be allowed to proceed during a fork but I can see that not allowing it is more a "foot shooting avoidance" than a requirement. it could be allowed that if you do a fork and allow multipel threads to runat the same time and end up with an inconsistant address space in the child, then you get what you deserve. :-) > - exit I think that's it.. It's certainly the 3 places we try single-thread. For exit, you allow the operation to complete as far as the buffer cache but you don't allow the thread to write it back to the address space. Writing back to the buffer cache (or whatever we call it now) should proceeed even if the thread has died. > > And any others I don't remember. We may find we need to perform an > aio drain wait there if we switch to doing AIO in the process context. I don't think so.. IO is really 2 stage: for read, data is read into the cache by standard async kernel code. then the thread wakes up and writes it to the user space. if the thread has died the async request is still allowed to complete. I believe this is the current state of affairs if a process gets a signal after requesting data from the filesystem, but before the filesystem has delivered it from teh device. The IO operation os not aborted, but the data is not used after it has been deleivered to the buffer cache. > > Robert N M Watson > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D56E79.60504>