On Mon, 2011-07-11 at 20:47 -0400, Jeff Layton wrote: > On Mon, 11 Jul 2011 16:12:24 -0400 > Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: > > > On Mon, 2011-07-11 at 16:08 -0400, Jeff Layton wrote: > > > On Mon, 11 Jul 2011 13:58:30 -0400 > > > bjschuma@xxxxxxxxxx wrote: > > > > > > > From: Bryan Schumaker <bjschuma@xxxxxxxxxx> > > > > > > > > If the client loses a lock, we send SIGIO to the application to notify > > > > it. The application can then handle the error from there. > > > > > > > > Signed-off-by: Bryan Schumaker <bjschuma@xxxxxxxxxx> > > > > > > Would SIGLOST be a better choice? Linux hasn't supported that > > > historically, but we could add it. > > > > SIGLOST is 'defined' in the kernel as follows: > > > > #define SIGIO 29 > > #define SIGPOLL SIGIO > > /* > > #define SIGLOST 29 > > */ > > > > IOW: it is synonymous with SIGPOLL and SIGIO. This explains Bryan's > > choice. > > > > Cheers > > Trond > > > > Right. I just wonder whether we'd be better off making this a distinct > signal with its own number. It seems like there would be value in being > able to distinguish between SIGLOST and SIGIO. Actually, I think there is value in distinguishing between SIGIO and SIGPOLL too, but it would appear that it is a bit late to do that. Note that we can (and probably should) use a siginfo structure to pass a bit more info to the application. That would mean filling out a siginfo and then replacing kill_pid() with kill_pid_info(), but that should be easily doable and can be made to resolve the above ambiguities. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
