Re: [fuse-devel] Re: more on multithreaded execution on fuse...

[Miklos S. <mi...@sz...>]

> > Well it could, except for one thing: operations currently can only be
> > interrupted with SIGKILL, which means that the second pwrite simply
> > won't happen.
> >
> > If interrupting with other signals were allowed, then this condition
> > would have to be dealt with in the library.
> 
> Hm, in FreeBSD I let any interrupt take effect. I don't see though how
> in-kernel interrupt handling affects the operation of the lib...
> 
> When the syscall is interrupted, the calling thread is woken up with
> error, which will imply that either the request gets dequeued from the
> upgoing queue (if we get at it early on) or marked as junk in the
> response queue (existing or future response gets neglected).
> 
> These are really internal matters of the kernel, the lib won't know of
> it -- the lib either completes its handler or won't call it at all.

Yes.  The only problem for the lib and the filesystem is that the old
interrupted request is still being executed, while a new one which may
conflict with the old can be started.

Let's take the earlier example:

pwrite("100 bytes, at pos 50")
pwrite("different 100 bytes, also at pos 50")

If the first one is interrupted, it returns EINTR.  Then it calls the
second one.  But now nothing guarantees that the filesystem will
perform the first write before the second one.  They may be handled by
different threads, and the second one may get scheduled before the
first one, which means, that the data written by the second pwrite
will be overwritten by the first.

Also SUS says that if a write() syscall has already written some
data before being interrupted it has to return the number of bytes
written.  But the kernel has no idea what that may be if the write is
interrupted.

That said, NFS does have an 'intr' option, that allows interruption of
operations.  We could take a look at how NFS deals with the above
problems.

> Are things fundamentally different in Linux so that the SIGKILL
> constraint is needed?

I don't thik this problem is specific to Linux.

> Or you just want to be more compliant with unixy fs semantics?

It's not unixy in the sense, that according to SUS, read and write
_can_ be interrupted, although most other file operations can't.

But some applications seem to rely on the fact that they are never
interrupted.  Here's the changelog entry documenting why
interruptibility was disabled:

2005-05-12  Miklos Szeredi <mi...@sz...>

	    * File save in krusader and other editors doesn't work with sshfs,
	    because open() is interrupted by a periodic signal, and open()
	    restarts forever, without any progress.  This could just be fixed
	    in open(), but the problem is more generic: if signals are
	    received more often than the filesystem can get the request to
	    userspace, it will never finish.  This is probably only a
	    theoretical problem, nevertheless I'm removing the possibility to
	    interrupt requests with anything other than SIGKILL, even before
	    being sent to userspace.  Bugreport by Eduard Czimbalmos.

Miklos