Subject: RE: Issue 94 (cleanup after ^C)

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 19 Jul 2002 08:27:09 -0700

Before you go off and write something about this, take a look at
section 8.6 in the July spec.  Although it doesn't mention ^C,
it does talk about UNIX signals as possibly aborting a request
and the consequences.  So I don't see that there's too much for
you to write.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 2:49 PM
To: Noveck, Dave
Cc: [email-masked]'
Subject: Issue 94 (cleanup after ^C)

Thanks for the gargantuan issue review.

I think I will respond using separate emails for separate issues.

You listed Issue 94 as not worth holding the spec up for.

>>>>> "Dave" == Dave Noveck <Noveck> writes:

    Dave> Issue 94: Clarify the responsibility of the client to "clean
    Dave> up" state at the server for operations that may be aborted
    Dave> at the client. For example, if an application is awaiting a
    Dave> lock request and that application is killed at the client
    Dave> (Unix ^C), the client is responsible for ensuring that lock
    Dave> request in progress with the server is accounted for. This
    Dave> means that the client may release the application so that it
    Dave> may be stopped before receiving a response from the server
    Dave> for the lock request but an appropriate UNLOCK and CLOSE
    Dave> must be done. There are other places where this type of
    Dave> state clean up is required of the client.

    Dave>      I think going in this direction is a mistake.  It gets
    Dave>      way to much into the details of client implementations.
    Dave>      The principle is that if you do something that creates
    Dave>      state you have to undo that.  The whole thing about
    Dave>      applications and control-C is solely within the purview
    Dave>      of the client implementation.

I agree that the spec should not get too far into implementation
details (for some definition of "too far").  

On the other hand, this issue (what the client should do if the user
hits ^C while waiting for a lock) has been a major, recurring headache
for prior versions of NFS.  If there is verbage we can put in the spec
so that clients are more likely to get this right, I see that as a
Very Good Thing.

Sigh, I guess this means I'm signing up to write the verbage, eh?

mike

---

From: [email-masked]
Date: Thu, 25 Jul 2002 14:57:57 -0700

>>>>> "Dave" == Dave Noveck <Noveck> writes:

    Dave> Before you go off and write something about this, take a
    Dave> look at section 8.6 in the July spec.  Although it doesn't
    Dave> mention ^C, it does talk about UNIX signals as possibly
    Dave> aborting a request and the consequences.  So I don't see
    Dave> that there's too much for you to write.

Yup, Section 8.6 seems sufficient, at least for lock operations, which
is what I was primarily concerned about.

Unless there are other situations where client cleanup is needed, I'd
say that Issue 94 has been resolved.

mike