Skip site navigation (1)Skip section navigation (2)
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>