WaitAsynchronous (Daemon function) - Revision history

JAL2: /* Exceptions */

2012-07-08T20:53:57Z

Exceptions

← Older revision		Revision as of 20:53, 8 July 2012
Line 27:		Line 27:
	This subroutine can throw the following exception:		This subroutine can throw the following exception:

	<dl>		<table class="syntaxTable">
	<dt><var>[[DaemonLost class\|DaemonLost]]</var>		<tr><th><var>[[DaemonLost class\|DaemonLost]]</var></th>
	<dd>If the daemon object is lost (probably restarted), a <var>DaemonLost</var> exception is thrown. This exception will only be thrown in <var class="product">Sirius Mods</var> version 7.2 and later.		<td>If the daemon object is lost (probably restarted), a <var>DaemonLost</var> exception is thrown. This exception will only be thrown in <var class="product">Sirius Mods</var> version 7.2 and later. </td></tr>
	</dl>		</table>

	==Usage notes==		==Usage notes==

JAL2: /* Exceptions */

2012-05-31T23:18:15Z

Exceptions

← Older revision		Revision as of 23:18, 31 May 2012
Line 25:		Line 25:
	==Exceptions==		==Exceptions==

	This subroutine can throw the following ~~exceptions~~:		This subroutine can throw the following exception:

	<dl>		<dl>

JAL2: /* Syntax terms */

2012-05-31T23:17:53Z

Syntax terms

← Older revision		Revision as of 23:17, 31 May 2012
Line 19:		Line 19:

	<tr><th><var>Info</var></th>		<tr><th><var>Info</var></th>
	<td>An optional, name required argument that indicates a second output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnInfoObject (Daemon subroutine)\|ReturnInfoObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of this argument must be deep copyable~~, as described in [[Copying objects\|"Copying objects"]]~~.		<td>An optional, name required argument that indicates a second output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnInfoObject (Daemon subroutine)\|ReturnInfoObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of this argument must be deep copyable.
	<p>Because this is an output argument, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.</p></td></tr>		<p>Because this is an output argument, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.</p></td></tr>
	</table>		</table>

JAL2 at 22:39, 31 May 2012

2012-05-31T22:39:03Z

← Older revision		Revision as of 22:39, 31 May 2012
Line 1:		Line 1:
	{{Template:Daemon:WaitAsynchronous subtitle}}		{{Template:Daemon:WaitAsynchronous subtitle}}

	~~<var>WaitAsynchronous</var> is a member of the <var>[[Daemon class\|Daemon]]</var> class.~~		This [[Notation conventions for methods#Callable methods\|callable]] method waits for the completion of the <var>[[RunAsynchronously (Daemon subroutine)\|RunAsynchronously]]</var> or <var>[[ContinueAsynchronously (Daemon subroutine)\|ContinueAsynchronously]]</var> processing on a daemon thread, and it retrieves various outputs from those methods.

	This [[Notation conventions for methods#Callable methods\|callable]] method waits for the completion of ~~the commands issued on a daemon thread by~~ the <var>[[RunAsynchronously (Daemon subroutine)\|RunAsynchronously]]</var> subroutine, and it retrieves various outputs from those ~~commands~~.

	==Syntax==		==Syntax==

JAL2: /* Exceptions */

2012-05-31T22:30:07Z

Exceptions

← Older revision		Revision as of 22:30, 31 May 2012
Line 30:		Line 30:

	<dl>		<dl>
	<dt>DaemonLost		<dt><var>[[DaemonLost class\|DaemonLost]]</var>
	<dd>If the daemon object is lost (probably restarted), a <var>[[DaemonLost ~~class\|DaemonLost]]~~</var> exception is thrown. This exception will only be thrown in <var class="product">Sirius Mods</var> version 7.2 and later.		<dd>If the daemon object is lost (probably restarted), a <var>DaemonLost</var> exception is thrown. This exception will only be thrown in <var class="product">Sirius Mods</var> version 7.2 and later.
	</dl>		</dl>

JAL2: /* Syntax terms */

2012-05-31T22:26:54Z

Syntax terms

← Older revision		Revision as of 22:26, 31 May 2012
Line 12:		Line 12:
	<tr><th>%sl</th>		<tr><th>%sl</th>
	<td>If specified, a <var>Stringlist</var> object that contains the terminal output from the command or commands run on the daemon thread. </td></tr>		<td>If specified, a <var>Stringlist</var> object that contains the terminal output from the command or commands run on the daemon thread. </td></tr>

	<tr><th>daemon</th>		<tr><th>daemon</th>
	<td>A <var>Daemon</var> object. </td></tr>		<td>A <var>Daemon</var> object. </td></tr>
	<tr><th>~~object~~</th>
			<tr><th><var>Output</var></th>
	<td>An output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnObject (Daemon subroutine)\|ReturnObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of <var class="term">object</var> must be deep copyable, as described in [[Copying objects\|"Copying objects"]].		<td>An output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnObject (Daemon subroutine)\|ReturnObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of <var class="term">object</var> must be deep copyable, as described in [[Copying objects\|"Copying objects"]].
	<p>Because <var class="term">object</var> is an output variable, it cannot itself be contained inside an object: that is, it must be a local or a common %variable. </p></td></tr>		<p>Because <var class="term">object</var> is an output variable, it cannot itself be contained inside an object: that is, it must be a local or a common %variable. </p></td></tr>

	<tr><th><var>Info</var></th>		<tr><th><var>Info</var></th>
	<td>An optional, name required argument that indicates a second output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnInfoObject (Daemon subroutine)\|ReturnInfoObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of this argument must be deep copyable, as described in [[Copying objects\|"Copying objects"]].		<td>An optional, name required argument that indicates a second output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnInfoObject (Daemon subroutine)\|ReturnInfoObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of this argument must be deep copyable, as described in [[Copying objects\|"Copying objects"]].

JAL2: /* Usage notes */

2012-05-22T20:56:37Z

Usage notes

← Older revision		Revision as of 20:56, 22 May 2012
Line 60:		Line 60:
	</p>		</p>

	Note that this will buy nothing if the requests are CPU-intensive and the request is not running with <code>AMPSUBS > 0</code> (requires <var class="product">MP/204</var>). Note also that if the daemons hold or require record locks that might conflict with each other, such a split will not work. Finally, since <var>RunAsynchronously</var> is not allowed for a transactional daemon, such a split is not feasible for transactional daemons.</ul>		Note that this will buy nothing if the requests are CPU-intensive and the request is not running with <code>AMPSUBS > 0</code> (requires <var class="product">MP/204</var>). Note also that if the daemons hold or require record locks that might conflict with each other, such a split will not work. Finally, since <var>RunAsynchronously</var> is not allowed for a transactional daemon, such a split is not feasible for transactional daemons.

			<li>For more information about asynchronous daemons, see [[Daemon class#Asynchronous and Independent daemons\|"Asynchronous and Independent daemons"]].
			</ul>

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

JAL2 at 17:20, 23 February 2012

2012-02-23T17:20:43Z

← Older revision		Revision as of 17:20, 23 February 2012
Line 1:		Line 1:
	{{Template:Daemon:WaitAsynchronous subtitle}}		{{Template:Daemon:WaitAsynchronous subtitle}}

	WaitAsynchronous is a member of the [[Daemon class]]		<var>WaitAsynchronous</var> is a member of the <var>[[Daemon class\|Daemon]]</var> class.

	This callable method waits for the completion of the commands issued on a daemon thread by the <var>[[RunAsynchronously (Daemon subroutine)\|RunAsynchronously]]</var> subroutine, and it retrieves various outputs from those commands.		This [[Notation conventions for methods#Callable methods\|callable]] method waits for the completion of the commands issued on a daemon thread by the <var>[[RunAsynchronously (Daemon subroutine)\|RunAsynchronously]]</var> subroutine, and it retrieves various outputs from those commands.

	==Syntax==		==Syntax==
	{{Template:Daemon:WaitAsynchronous syntax}}		{{Template:Daemon:WaitAsynchronous syntax}}

	===Syntax terms===		===Syntax terms===
	<table class="syntaxTable">		<table class="syntaxTable">
Line 14:		Line 15:
	<td>A <var>Daemon</var> object. </td></tr>		<td>A <var>Daemon</var> object. </td></tr>
	<tr><th>object</th>		<tr><th>object</th>
	<td>An output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnObject (Daemon subroutine)\|ReturnObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of <var class="term">object</var> must be deep copyable, as described in [[Copying objects]].		<td>An output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnObject (Daemon subroutine)\|ReturnObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of <var class="term">object</var> must be deep copyable, as described in [[Copying objects\|"Copying objects"]].
	<p>Because <var class="term">object</var> is an output variable, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.		<p>Because <var class="term">object</var> is an output variable, it cannot itself be contained inside an object: that is, it must be a local or a common %variable. </p></td></tr>
	</p></td></tr>
	<tr><th><var>Info</var></th>		<tr><th><var>Info</var></th>
	<td>An optional, name required argument that indicates a second output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnInfoObject (Daemon subroutine)\|ReturnInfoObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of this argument must be deep copyable, as described in [[Copying objects]].		<td>An optional, name required argument that indicates a second output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnInfoObject (Daemon subroutine)\|ReturnInfoObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of this argument must be deep copyable, as described in [[Copying objects\|"Copying objects"]].
	<p>Because this is an output argument, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.</p></td></tr>		<p>Because this is an output argument, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.</p></td></tr>
	</table>		</table>
Line 35:		Line 35:

	<li><var>WaitAsynchronous</var> was introduced in <var class="product">Sirius Mods</var> version 7.0.		<li><var>WaitAsynchronous</var> was introduced in <var class="product">Sirius Mods</var> version 7.0.
	<li>If <var>WaitAsynchronous</var> is issued against a <var>Daemon</var> object that is not currently running asynchronously (that is, if <var>RunAsynchronously</var> was not issued against it), the request is canceled. Note that this does not mean that the <var>Daemon</var> must actually still be running -- if the daemon thread has run all the commands in the <var>RunAsynchronously</var> call, not only is <var>WaitAsynchronous</var> allowed, it is required before anything else can be done with the <var>Daemon</var>. And, in any case, it's the only way of retrieving the outputs from the asynchronous request.		<li>If <var>WaitAsynchronous</var> is issued against a <var>Daemon</var> object that is not currently running asynchronously (that is, if <var>RunAsynchronously</var> was not issued against it), the request is canceled. Note that this does not mean that the <var>Daemon</var> must actually still be running — if the daemon thread has run all the commands in the <var>RunAsynchronously</var> call, not only is <var>WaitAsynchronous</var> allowed, it is required before anything else can be done with the <var>Daemon</var>. And, in any case, it's the only way of retrieving the outputs from the asynchronous request.

	<li>This is an example <var>WaitAsynchronous</var> call:		<li>This is an example <var>WaitAsynchronous</var> call:
Line 43:		Line 43:
	</p>		</p>

	<li>The output <var>Stringlist</var> and parameters from <var>WaitAsynchronous</var> are identical to the output <var>Stringlist</var> and parameters for the <var>[[Run (Daemon function)\|Run]]</var> method, so see [[Daemon class]] for more information on and examples of output <var>Stringlists</var> and objects.		<li>The output <var>Stringlist</var> and parameters from <var>WaitAsynchronous</var> are identical to the output <var>Stringlist</var> and parameters for the <var>[[Run (Daemon function)\|Run]]</var> method, so see [[Daemon class\|"Daemon class"]] for more information on and examples of output <var>Stringlists</var> and objects.
	<li>The inputs and outputs from the combination of <var>RunAsynchronously</var> and <var>WaitAsynchronous</var> are identical to the inputs and outputs from the <var>Run</var> method. As such, it should be a relatively simple task to split a <var>Run</var> invocation into <var>RunAsynchronously</var> and <var>WaitAsynchronous</var> invocations, allowing the daemon processing to be performed in parallel with parent thread processing or the processing on another daemon thread.		<li>The inputs and outputs from the combination of <var>RunAsynchronously</var> and <var>WaitAsynchronous</var> are identical to the inputs and outputs from the <var>Run</var> method. As such, it should be a relatively simple task to split a <var>Run</var> invocation into <var>RunAsynchronously</var> and <var>WaitAsynchronous</var> invocations, allowing the daemon processing to be performed in parallel with parent thread processing or the processing on another daemon thread.

Line 60:		Line 60:
	</p>		</p>

	Note that this will buy nothing if the requests are CPU-intensive and the request is not running with AMPSUBS>0 (requires MP/204). Note also that if the daemons hold or require record locks that might conflict with each other, such a split will not work. Finally, since <var>RunAsynchronously</var> is not allowed for a transactional daemon, such a split is not feasible for transactional daemons.</ul>		Note that this will buy nothing if the requests are CPU-intensive and the request is not running with <code>AMPSUBS > 0</code> (requires <var class="product">MP/204</var>). Note also that if the daemons hold or require record locks that might conflict with each other, such a split will not work. Finally, since <var>RunAsynchronously</var> is not allowed for a transactional daemon, such a split is not feasible for transactional daemons.</ul>

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

Dme at 16:45, 8 February 2012

2012-02-08T16:45:11Z

← Older revision		Revision as of 16:45, 8 February 2012
Line 3:		Line 3:
	WaitAsynchronous is a member of the [[Daemon class]]		WaitAsynchronous is a member of the [[Daemon class]]

	This callable method waits for the completion of the commands issued on a daemon thread by the [[RunAsynchronously (Daemon ~~function~~)]], and it retrieves various outputs from those commands.		This callable method waits for the completion of the commands issued on a daemon thread by the <var>[[RunAsynchronously (Daemon subroutine)\|RunAsynchronously]]</var> subroutine, and it retrieves various outputs from those commands.

	==Syntax==		==Syntax==
Line 9:		Line 9:
	===Syntax terms===		===Syntax terms===
	<table class="syntaxTable">		<table class="syntaxTable">
	<tr><th>%~~strL~~</th>		<tr><th>%sl</th>
	<td>If specified, a Stringlist object that contains the terminal output from the command or commands run on the daemon thread. </td></tr>		<td>If specified, a <var>Stringlist</var> object that contains the terminal output from the command or commands run on the daemon thread. </td></tr>
	<tr><th>~~%daem~~</th>		<tr><th>daemon</th>
	<td>A ~~previously defined~~ Daemon object. </td></tr>		<td>A <var>Daemon</var> object. </td></tr>
	<tr><th>~~%outputObj~~</th>		<tr><th>object</th>
	<td>~~The~~ object returned ~~from~~ the daemon ~~method object by~~ the [[ReturnObject(Daemon ~~function~~)]] invoked on the daemon thread. This ~~optional argument~~ is ~~passed~~ by deep copy and not by reference, so ~~'''%outputObj'''~~ must be deep copyable, as described in [[Copying objects~~]]. The object set to %outputObj is the object passed by the daemon thread using the [[ReturnObject(Daemon function)~~]].		<td>An output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnObject (Daemon subroutine)\|ReturnObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of <var class="term">object</var> must be deep copyable, as described in [[Copying objects]].
	<p>Because ~~'''%outputObj'''~~ is an output variable, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.		<p>Because <var class="term">object</var> is an output variable, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.
	</p></td></tr>		</p></td></tr>
	<tr><th><var>Info</var></th>		<tr><th><var>Info</var></th>
	<td>An optional, name required ~~parameter~~ that indicates a second output object returned ~~from~~ the daemon ~~method object by~~ the [[ReturnInfoObject(Daemon ~~function~~)]] invoked on the daemon thread. ~~The~~ object set ~~to %infoObj is the object passed by the daemon thread using the ReturnInfoObject method.~~		<td>An optional, name required argument that indicates a second output %variable which is set to the object returned by the daemon thread using the <var>[[ReturnInfoObject (Daemon subroutine)\|ReturnInfoObject]]</var> subroutine invoked on the daemon thread. This object is set by deep copy and not by reference, so the class of this argument must be deep copyable, as described in [[Copying objects]].
	~~<p>This optional argument is passed~~ by deep copy and not by reference, so ~~'''%infoObj'''~~ must be deep copyable, as described in [[Copying objects]].~~</p>~~		<p>Because this is an output argument, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.</p></td></tr>
	<p>Because ~~'''%infoObj'''~~ is an output ~~variable~~, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.</p></td></tr>
	</table>		</table>

Line 29:		Line 28:
	<dl>		<dl>
	<dt>DaemonLost		<dt>DaemonLost
	<dd>If the daemon object is lost (probably restarted), a DaemonLost exception is thrown. This exception will only be thrown in ~~''[[~~Sirius Mods~~]]''~~.		<dd>If the daemon object is lost (probably restarted), a <var>[[DaemonLost class\|DaemonLost]]</var> exception is thrown. This exception will only be thrown in <var class="product">Sirius Mods</var> version 7.2 and later.
	</dl>		</dl>

Line 35:		Line 34:
	<ul>		<ul>

	<li>WaitAsynchronous was introduced in ~~''[[~~Sirius Mods~~]]'' Version~~ 7.0.		<li><var>WaitAsynchronous</var> was introduced in <var class="product">Sirius Mods</var> version 7.0.
	<li>If WaitAsynchronous is issued against a ~~daemon~~ object that is not currently running asynchronously (RunAsynchronously was issued against it), the request is canceled. Note that this does not mean that the ~~daemon~~ must actually still be running -- if the daemon thread has run all the commands in the RunAsynchronously call, not only is WaitAsynchronous allowed, it is required before anything else can be done with the ~~daemon~~. And, in any case, it's the only way of retrieving the outputs from the asynchronous request.		<li>If <var>WaitAsynchronous</var> is issued against a <var>Daemon</var> object that is not currently running asynchronously (that is, if <var>RunAsynchronously</var> was not issued against it), the request is canceled. Note that this does not mean that the <var>Daemon</var> must actually still be running -- if the daemon thread has run all the commands in the <var>RunAsynchronously</var> call, not only is <var>WaitAsynchronous</var> allowed, it is required before anything else can be done with the <var>Daemon</var>. And, in any case, it's the only way of retrieving the outputs from the asynchronous request.

	<li>This is an example WaitAsynchronous call:		<li>This is an example <var>WaitAsynchronous</var> call:
	<p class="code">%daem:runAsynchronously(%commands)		<p class="code">%daem:runAsynchronously(%commands)
	...		...
Line 44:		Line 43:
	</p>		</p>

	<li>The output Stringlist and parameters from WaitAsynchronous are identical to the output Stringlist and parameters for the Run method, so see [[Daemon class]]. for more information on and examples of output Stringlists and objects.		<li>The output <var>Stringlist</var> and parameters from <var>WaitAsynchronous</var> are identical to the output <var>Stringlist</var> and parameters for the <var>[[Run (Daemon function)\|Run]]</var> method, so see [[Daemon class]] for more information on and examples of output <var>Stringlists</var> and objects.
	<li>The inputs and outputs from the combination of RunAsynchronously and WaitAsynchronous are identical to the inputs and outputs from the Run method. As such, it should be a relatively simple task to split a Run into a RunAsynchronously and WaitAsynchronous, allowing the daemon processing to be performed in parallel with parent thread processing or the processing on another daemon thread.		<li>The inputs and outputs from the combination of <var>RunAsynchronously</var> and <var>WaitAsynchronous</var> are identical to the inputs and outputs from the <var>Run</var> method. As such, it should be a relatively simple task to split a <var>Run</var> invocation into <var>RunAsynchronously</var> and <var>WaitAsynchronous</var> invocations, allowing the daemon processing to be performed in parallel with parent thread processing or the processing on another daemon thread.

	For example, if a request has the following statements:		For example, if a request has the following statements:
Line 53:		Line 52:
	</p>		</p>

	The statements can be easily split up into the following, and the processing on the two ~~daemons~~ would be performed in parallel with each other:		The statements can be easily split up into the following, and the processing on the two <var>Daemon</var>s would be performed in parallel with each other:

	<p class="code">%daem1:runAsynchronously(%cmds1, %inobj1)		<p class="code">%daem1:runAsynchronously(%cmds1, %inobj1)
Line 61:		Line 60:
	</p>		</p>

	Note that this will buy nothing if the requests are CPU-intensive and the request is not running with AMPSUBS>0 (requires MP/204). Note also that if the daemons hold or require record locks that might conflict with each other, such a split will not work. Finally, since RunAsynchronously is not allowed for a transactional daemon, such a split is not feasible for transactional daemons.</ul>		Note that this will buy nothing if the requests are CPU-intensive and the request is not running with AMPSUBS>0 (requires MP/204). Note also that if the daemons hold or require record locks that might conflict with each other, such a split will not work. Finally, since <var>RunAsynchronously</var> is not allowed for a transactional daemon, such a split is not feasible for transactional daemons.</ul>

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

JAL2: /* Syntax terms */

2011-04-13T00:05:51Z

Syntax terms

← Older revision		Revision as of 00:05, 13 April 2011
Line 17:		Line 17:
	<p>Because '''%outputObj''' is an output variable, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.		<p>Because '''%outputObj''' is an output variable, it cannot itself be contained inside an object: that is, it must be a local or a common %variable.
	</p></td></tr>		</p></td></tr>
	<tr><th><var>Info~~=%infoObj~~</var></th>		<tr><th><var>Info</var></th>
	<td>An optional, name required parameter that indicates a second output object returned from the daemon method object by the [[ReturnInfoObject(Daemon function)]] invoked on the daemon thread. The object set to %infoObj is the object passed by the daemon thread using the ReturnInfoObject method.		<td>An optional, name required parameter that indicates a second output object returned from the daemon method object by the [[ReturnInfoObject(Daemon function)]] invoked on the daemon thread. The object set to %infoObj is the object passed by the daemon thread using the ReturnInfoObject method.
	<p>This optional argument is passed by deep copy and not by reference, so '''%infoObj''' must be deep copyable, as described in [[Copying objects]].</p>		<p>This optional argument is passed by deep copy and not by reference, so '''%infoObj''' must be deep copyable, as described in [[Copying objects]].</p>