Re: wait queue process state

[jw schultz]

On Tue, May 28, 2002 at 09:57:41AM +0200, Terje Eggestad wrote:
> Well, the only reason I'm aware of is that your have system calls that
> can't be interrupted, and sys calls that can (and when they do they
> return -1 and errno=EINTR). 
> 
> The number of syscall that actually can return EINTR is actually fairly
> small. And some like read()/write() may or may not depending on the type
> of file. If the file is a socket it usually can, but if it's a regular
> file it can't. 
> 
> A regular file access is as you uninteruptable as you point out, and to
> top it of it can be made nonblocking. The reason is that a regular file
> IO is deterministic, it must succeed or fail ASAP, and if it fail it's
> either a full FS, or a corrupt FS or a HW failure. (The latter two req
> reboot/HW repair, the first is a "normal" case). Socket IO is
> nondeterministic and we need a way to interrupt it. 
> 
> I guess deterministic/nondeterministic activities is one way to describe
> either a kernel task is interruptable or nor. Another rule of thumb is
> that you're noninteruptable if you're waiting for HW to complete a task.
> (If you don't want to wait, you should have done it async anyway). 
> You're interruptable if you wait for another program to do a task.
> 
> 
> Make sense?
> 
> TJ

I'm not going to speak to whether this is true in the
current kernels or not.

The read system call is interuptable, period.  Disk access
is considered slow.   If you code asuming it will not be
interupted or that an interupt will cause a return of -1
your code may break on Linux and will certainly not be
portable.

POSIX is ambigious on this and disk reads (on UNIX) have
historically returned partial data when interupted during a
disk read where some of the data was already in buffer.

>  
> 
> On Mon, 2002-05-27 at 23:11, Joseph Cordina wrote:
> > Hi,
> >    I am quite new to this list and thus does not know if this question 
> > has been answered many a times. I have looked in the archive but could 
> > not find it. Here goes anyway:
> >      I realised that when processes are placed in the wait queue, they 
> > are set at either INTERRUPTIBLE or NONINTERRUPTIBLE. I also noticed that 
> > something like file access is set as NONINTERRUPTIBLE. Could someone 
> > please tell me the reason for having these two states. I can understand 
> > that INTERRUPTIBLE can be made to be interrupted by a timer or a signal 
> > and vice versa for UNTERRUPTIBLE. Yet what makes blocking system calls 
> > as INTERRUPTIBLE or NONINTERRUPTIBLE. Also why is file access considered 
> > as NONINTERRUPTIBLE.
> > 
> > In addition, inside the kernel running, are these two different states 
> > treated differently (apart from the allowance to be interrupted or 
> > otherwise).
> > 
> > The reason I am asking is that I am working on scheduler activations 
> > which allow new kernel threads to be created when a kernel thread blocks 
> > inside the kernel. Yet this only works for INTERRUPTIBLE processes, I 
> > was thinking of making it work also for NONINTERRUPTIBLE processes. Just 
> > wondering if this would have any repurcusions. Also when a process 
> > generates a page fault which causes a page to be retreived from the 
> > filesystem, it such a process placed in the wait queue as 
> > NONINTERRUPTIBLE also ?
> > 
> > Cheers
> > 
> > Joseph Cordina
> > University of Malta
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [e-mail]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> -- 
> _________________________________________________________________________
> 
> Terje Eggestad                  mailto:[e-mail]
> Scali Scalable Linux Systems    http://www.scali.com
> 
> Olaf Helsets Vei 6              tel:    [phone] (OFFICE)
> P.O.Box 150, Oppsal                     [phone]  (MOBILE)
> N-0619 Oslo                     fax:    [phone]
> NORWAY            
> _________________________________________________________________________
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		[e-mail]

		Remember Cernan and Schmitt