ContinueAsynchronously (Daemon subroutine): Difference between revisions

From m204wiki
Jump to navigation Jump to search
mNo edit summary
 
(16 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Template:Daemon:ContinueAsynchronously subtitle}}
{{Template:Daemon:ContinueAsynchronously subtitle}}


This page is [[under construction]].
This method tells a daemon that issued a <var>Daemon</var> class <var>[[ReturnToMaster (Daemon subroutine)|ReturnToMaster]]</var> call to continue processing from the point of that <var>ReturnToMaster</var> call. Unlike the <var>[[Continue (Daemon function)|Continue]]</var> method, <var>ContinueAsynchronously</var> returns immediately, thus allowing the thread that issued <var>ContinueAsynchronously</var> to run in parallel with the daemon thread.


==Syntax==
==Syntax==
Line 10: Line 10:
<tr><th>daemon</th>
<tr><th>daemon</th>
<td>A previously defined <var>Daemon</var> object. </td></tr>
<td>A previously defined <var>Daemon</var> object. </td></tr>
<tr><th>inputObj</th>
<tr><th><var>Input</var></th>
<td>This optional, [[Notation conventions for methods#Named parameters|name allowed]], argument is either:
<td>This optional, [[Notation conventions for methods#Named parameters|name allowed]], argument is an object passed to the <var class="term">daemon</var> thread. This object must be deep copyable, as described in: [[Copying objects|"Copying objects"]]. </td></tr>
<ul>
<li>An object passed to the <var class="term">daemon</var> thread. This object must be deep copyable, as described in: [[Copying objects|"Copying objects"]].
<li>A Boolean value. If a Null object
</ul>
</table>
</table>
==Exceptions==
This subroutine can throw the following exceptions:
<dl>
<dt><var>[[IncorrectDaemonState class|IncorrectDaemonState]]</var>
<dd>If the daemon thread is not in a <var>ReturnToMaster</var> wait when <var>ContinueAsynchronously</var> is issued,
an <var>IncorrectDaemonState</var> exception is thrown. This exception will only be thrown in <var class="product">Sirius Mods</var> version 8.1 and later.
<dt><var>[[DaemonLost_class|DaemonLost]]</var>
<dd>If <var class="term">daemon</var> is lost (probably restarted), a <var>DaemonLost</var> exception is thrown. Since <var>ContinueAsynchronously</var> does not wait for the <var>daemon</var> thread to do anything, a <var>DaemonLost</var> exception indicates that the daemon thread was lost <b><i>before</i></b> <var>ContinueAsynchronously</var> was invoked.
</dl>


==Usage notes==
==Usage notes==
<ul>
<ul>
<li>Issuing <var>ContinueAsynchronously</var> against a daemon not in a <var>ReturnToMaster</var> wait results in an <var>[[IncorrectDaemonState class|IncorrectDaemonState]]</var> exception.</li>
<li>The <var>[[Continue (Daemon function)|Continue]]</var> and <var>[[ContinueIndependently (Daemon subroutine)|ContinueIndependently]]</var> methods also tell a daemon to continue from a <var>ReturnToMaster</var> wait.</li>
<li>The <var>[[Continue (Daemon subroutine)|Continue]]</var> and <var>[[ContinueIndependently (Daemon subroutine)|ContinueIndependently]]</var> methods also tell a daemon to continue from a <var>ReturnToMaster</var> wait.</li>
 
<li>Issuing <var>ContinueAsynchronously</var> against a [[Daemon class#Transactional daemons|transactional daemon]] results in request cancellation.
 
<li>If the <var class="term">daemon</var> thread and its daemons hold record locks that conflict with the parent thread's family (excluding the <var class="term">daemon</var> thread and its daemons), <var>ContinueAsynchronously</var> results in request cancellation.
 
<li>Once started via <var>ContinueAsynchronously</var>, the <var class="term">daemon</var> thread is considered to be running asynchronously until a <var>[[WaitAsynchronous (Daemon function)|WaitAsynchronous]]</var> is issued against the <var class="term">daemon</var> object. This is the case, even if the <var class="term">daemon</var> thread has completed processing all of the input commands.
 
<li>While the <var class="term">daemon</var> thread is running asynchronously, any methods that require interaction with it cause request cancellation.
 
<li><var>WaitAsynchronous</var> is used to retrieve any output from the commands run via <var>ContinueAsynchronously</var>. This includes the terminal output and any output or info object.
 
<li>For more information about asynchronous daemons, see [[Daemon class#Asynchronous and Independent daemons|"Asynchronous and Independent daemons"]].
</ul>
</ul>
==Examples==


==See also==
==See also==
{{Template:Daemon:ContinueAsynchronously footer}}
{{Template:Daemon:ContinueAsynchronously footer}}

Latest revision as of 22:56, 26 July 2012

Continue processing asynchronously in daemon (Daemon class)

[Introduced in Sirius Mods 8.1]


This method tells a daemon that issued a Daemon class ReturnToMaster call to continue processing from the point of that ReturnToMaster call. Unlike the Continue method, ContinueAsynchronously returns immediately, thus allowing the thread that issued ContinueAsynchronously to run in parallel with the daemon thread.

Syntax

daemon:ContinueAsynchronously[( [Input= object])] Throws DaemonLost, IncorrectDaemonState

Syntax terms

daemon A previously defined Daemon object.
Input This optional, name allowed, argument is an object passed to the daemon thread. This object must be deep copyable, as described in: "Copying objects".

Exceptions

This subroutine can throw the following exceptions:

IncorrectDaemonState
If the daemon thread is not in a ReturnToMaster wait when ContinueAsynchronously is issued, an IncorrectDaemonState exception is thrown. This exception will only be thrown in Sirius Mods version 8.1 and later.
DaemonLost
If daemon is lost (probably restarted), a DaemonLost exception is thrown. Since ContinueAsynchronously does not wait for the daemon thread to do anything, a DaemonLost exception indicates that the daemon thread was lost before ContinueAsynchronously was invoked.

Usage notes

  • The Continue and ContinueIndependently methods also tell a daemon to continue from a ReturnToMaster wait.
  • Issuing ContinueAsynchronously against a transactional daemon results in request cancellation.
  • If the daemon thread and its daemons hold record locks that conflict with the parent thread's family (excluding the daemon thread and its daemons), ContinueAsynchronously results in request cancellation.
  • Once started via ContinueAsynchronously, the daemon thread is considered to be running asynchronously until a WaitAsynchronous is issued against the daemon object. This is the case, even if the daemon thread has completed processing all of the input commands.
  • While the daemon thread is running asynchronously, any methods that require interaction with it cause request cancellation.
  • WaitAsynchronous is used to retrieve any output from the commands run via ContinueAsynchronously. This includes the terminal output and any output or info object.
  • For more information about asynchronous daemons, see "Asynchronous and Independent daemons".

See also