Subject: script mib suspend/resume issue

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Jul 2000 17:50:09 +0200

While working on the RFC 2592 revision, I ran into another interesting
question. I tried to add a description of the suspend / resume
operations to section 7. The interesting thing here is that the MIB
does not require suspend/resume capabilities in a language runtime.
So the procedure has to work correctly in all cases - regardless
whether suspend/resume is supported or not.

RFC 2592 says in the compliance statement the an implementation which
is told to suspend a script but which is unable to do so will put the
script into the suspending state until it either terminates or the
managers gives the command to resume the script.

The implication of this is that a manager can not figure out whether a
script can be suspended or not. Setting smRunControl to `suspend' and
then polling smRunState until the script is really suspended does not
work (unless you invent some strange timeouts).

Strawman: Change the compliance definition such that implementations
which are unable to suspend a script keep the script in the executing
state. This allows to set smRunControl to `suspend' and to poll
smRunState until it either contains `running' or `suspended'.

Comments?

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Eamonn McManus <[email-masked]>
Date: Tue, 04 Jul 2000 18:45:23 +0200

> smRunState until it either contains `running' or `suspended'.

I do not understand your last sentence.  It seems to me that if the semantics
are changed to what you suggest, the way to know whether suspension is supported
is to set smRunControl to "suspend" and then immediately read smRunState.  If it
is either "suspending" or "suspended", then suspension is supported.  If it is
"running", then suspension is not supported (or, someone else resumed the script
behind your back).  There is no need to poll.

I quite like today's semantics, where unsupported suspend appears like a suspend
that just takes forever to take effect.  But if you do want to have an
indication of whether your suspend is going to succeed or not, I think the right
thing is an appropriate SNMP error for the operation that tries to set
smRunControl to "suspend".

Éamonn

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Jul 2000 10:01:22 +0200

>>>>> Eamonn McManus writes:

>> Strawman: Change the compliance definition such that
>> implementations which are unable to suspend a script keep the
>> script in the executing state. This allows to set smRunControl to
>> `suspend' and to poll smRunState until it either contains `running'
>> or `suspended'.

Eamonn> I do not understand your last sentence.  It seems to me that
Eamonn> if the semantics are changed to what you suggest, the way to
Eamonn> know whether suspension is supported is to set smRunControl to
Eamonn> "suspend" and then immediately read smRunState.  If it is
Eamonn> either "suspending" or "suspended", then suspension is
Eamonn> supported.  If it is "running", then suspension is not
Eamonn> supported (or, someone else resumed the script behind your
Eamonn> back).  There is no need to poll.

What I propose is to make suspending a truly temporary state which
either leads to suspended or executing (if the operation failed for a
give script/runtime.

Eamonn> I quite like today's semantics, where unsupported suspend
Eamonn> appears like a suspend that just takes forever to take effect.
Eamonn> But if you do want to have an indication of whether your
Eamonn> suspend is going to succeed or not, I think the right thing is
Eamonn> an appropriate SNMP error for the operation that tries to set
Eamonn> smRunControl to "suspend".

The drawback of this option is that the suspend operation now becomes
synchronous. The agent has to wait until the script got suspended or
the suspend failed before it can send the response to the set request.
Depending on your implementation, this may not be desirable. In our
implementation, the SNMP agent sends out an SMX message to the runtime
system in order to suspend a running script. The response to this SMX
message indicates whether the suspend operation succeeded or not. It
would be hard to make assumptions on the time a runtime needs to come
back with a response.

                        smRunState		   runtime

		        executing
                            |
                            |
smRunControl = suspend      |       SMX suspend
----------------------> suspending ------------->   -+
<---------------------      |                        |
                            |       SMX response     |
                        executing  <------------    -+
---------------------->     |
<---------------------      |
get smRunState = executing  |
                            |
                            |
                            |
smRunControl = suspend      |       SMX suspend
----------------------> suspending ------------->   -+
<---------------------      |                        |
                            |       SMX response     |
                        suspended  <------------    -+
---------------------->     |
<---------------------      |
get smRunState = suspended  |

The figure above may be helpful to understand the proposal. 

Note that I do not require a suspending state. If an implemen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Jul 2000 12:53:19 +0200

>>>>> Eamonn McManus writes:

Eamonn> If an implementation is always unable to suspend scripts, it
Eamonn> will know that, and can immediately say so.  What you are
Eamonn> saying, though, is that an implementation might not know
Eamonn> whether it can actually suspend a given script at a given
Eamonn> moment until it actually tries it.  I knew that suspending a
Eamonn> script was not an instantaneous action, but what you are
Eamonn> saying is that even knowing whether suspending will work is
Eamonn> not necessarily instantaneous.

I think there are at least three different cases:

(a) The agent knows that you will never be able to suspend a script.
    The easiest case.

(b) The agent supports arbitrary runtime engines and it is not aware
    of the capabilities of each particular runtime. However, once the
    agent is aware of the runtime engine capabilities, then it knows
    whether the runtime supports suspend/resume or not. A bit more
    complex case because you need to invent a way to "learn" the
    suspend/resume capabilities of an arbitrary runtime engine.

(c) The runtime itself allows scripts to ignore suspend/resume. In
    this case, you will only find out whether suspend/resume works by
    actually trying it.

We are facing (b) and perhaps (c). An example for (c) would be a UNIX
process which ignores signals to stop the process. (To be fair, this
example is not too convincing since your can't ignore the STOP signal
as far as I know.) Another example would be a runtime engine which
uses a cooperative threading mechanism and which requires that the
thread actually returns the CPU and suspends itself.

Eamonn> This is only a problem if a script's suspendability can change
Eamonn> during its execution.  Is this the case for your SMX-based
Eamonn> implementation, or would it be possible to know at the moment
Eamonn> a script is launched whether future suspend requests for that
Eamonn> script will work?

We can solve the problem in our implementation if we define that
runtimes may never show the behaviour (c) and by inventing a mechanism
to "learn" whether a runtime is capable to do a suspend/resume (either
by having this information statically in a configuration file or by
doing a test suspend/resume when a script is started).

Eamonn> If the latter, are there other realistic examples where you
Eamonn> cannot immediately know at suspension time whether the
Eamonn> suspension will work?  If so, your solution does seem to be
Eamonn> the only reasonable one.  But such a system would be a very
Eamonn> strange one: is it really useful to have a suspend operation
Eamonn> that only works sometimes?

We can design the script MIB so that it works regardless what the
answer to this question is. Or we can answer this question and hope
that the answer we have given proves to be correct in all cases.

Anyway, I believe the current behaviour described in RFC 2592 is
really ugly. Both, the initial strawman proposal as well as the
proposal to send an inconsistentValue error in response to the 
suspend set operation are IMHO better than what we have now.

What do the other folks on this list think?

/js

---

From: Eamonn McManus <[email-masked]>
Date: Wed, 05 Jul 2000 12:21:03 +0200

> either leads to suspended or executing (if the operation failed for a

From what you describe later in your message, you were actually talking about a
somewhat different problem from what you said.  If an implementation is always
unable to suspend scripts, it will know that, and can immediately say so.  What
you are saying, though, is that an implementation might not know whether it can
actually suspend a given script at a given moment until it actually tries it.  I
knew that suspending a script was not an instantaneous action, but what you are
saying is that even knowing whether suspending will work is not necessarily
instantaneous.

This is only a problem if a script's suspendability can change during its
execution.  Is this the case for your SMX-based implementation, or would it be
possible to know at the moment a script is launched whether future suspend
requests for that script will work?  If the latter, are there other realistic
examples where you cannot immediately know at suspension time whether the
suspension will work?  If so, your solution does seem to be the only reasonable
one.  But such a system would be a very strange one: is it really useful to have
a suspend operation that only works sometimes?

Éamonn