Re: [bug report] NFS and uninterruptable wait states

[Jan Hudec]

> Timeouts are a completely separate issue, surely? Applications ought to be 
> able to deal with getting a _signal_ during a system call, whatever happens.
> 
> IMO, sleeping in state TASK_UNINTERRUPTIBLE in any situation where you can't
> prove that the wakeup _will_ happen and will happen _soon_ should be
> considered a bug - it's almost always just because someone hasn't bothered
> to implement the cleanup code required for dealing with being interrupted.
> 
> /me tries to work out why anyone would ever want filesystem accesses to be 
> uninterruptible.

generic_file_read does wait_on_page, which sleeps uninteruptibly. This
shouldn't be too difficult to change (once the pages are linked to file's
memory_area, generic_read_file redoes readpage on the same pages and it's
up to readpage to find out, weather the request is still pending or timed
out)

Other problem is the RPC layer. If it should check signal_pending only on
timeouts, it;s simple. If it should also check while waiting, it has to be
able to recognise the interupted call. And this in turn brings the problem
of discarding data requested by interupted and not restarted calls (eg. when
the process was killed by the signal). There is the nasty case when request
is sent to the server and sending process dies while waitig. But the request
is eventualy replied and the reply must be handled somewhere.

You are right about not bothering with cleanup code. But it's not easy to
have the RPC layer right.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <[e-mail]>