Daemon example: Difference between revisions
(Created page with "Sirius '''Daemons''' are a class of objects that run on a thread independent from the user who launched them. The thread that launches the Daemon is called the "master". The Da...") |
mNo edit summary |
||
Line 1: | Line 1: | ||
Sirius '''Daemons''' are a class of objects that run on a thread | Sirius '''Daemons''' are a class of objects that run on a thread other than the user that launched them. The thread that launches the Daemon is called the "parent". The Daemon responds to requests from the parent and may optionally pass back to the parent thread the results of commands and [[User Language]] programs. | ||
See the [[Daemon class]] and [[Daemon methods]] pages for detailed information on Daemons and Daemon behaviors. | See the [[Daemon class]] and [[Daemon methods]] pages for detailed information on Daemons and Daemon behaviors. | ||
Line 5: | Line 5: | ||
=Why use a Daemon?= | =Why use a Daemon?= | ||
Daemons make it easy to capture command output and User Language output to Stringlist objects. They make it easy to keep server sizes low by splitting work between a | Daemons make it easy to capture command output and User Language output to Stringlist objects. They make it easy to keep server sizes low by splitting work between a parent and daemon. The use of Asynchronous daemons allows work to be discharged in "fire and forget" mode, where the Daemon completes a task while the parent thread moves on to other processes. | ||
=Variable Find Conditions= | =Variable Find Conditions= | ||
Line 11: | Line 11: | ||
One problem often encountered in [[Model 204]] [[User Language]] is that FIND conditions are bound at compile time. Variable input to a fixed number of conditions, with an unchanging set of field names, is handled well in ordinary User Language. But User Language has no clean mechanism to programmatically set up and execute dynamically generated FINDs. | One problem often encountered in [[Model 204]] [[User Language]] is that FIND conditions are bound at compile time. Variable input to a fixed number of conditions, with an unchanging set of field names, is handled well in ordinary User Language. But User Language has no clean mechanism to programmatically set up and execute dynamically generated FINDs. | ||
Daemons handle this situation very elegantly. In the following program, a Daemon is instantiated, and a small program is built to FIND a set of records. The program is submitted to the Daemon in a [[Stringlist class|StringList]], and the resulting set of found records is returned to the | Daemons handle this situation very elegantly. In the following program, a Daemon is instantiated, and a small program is built to FIND a set of records. The program is submitted to the Daemon in a [[Stringlist class|StringList]], and the resulting set of found records is returned to the parent thread in a [[Recordset class#SortedRecordSet|SortedRecordSet]] object. | ||
Revision as of 15:24, 17 September 2010
Sirius Daemons are a class of objects that run on a thread other than the user that launched them. The thread that launches the Daemon is called the "parent". The Daemon responds to requests from the parent and may optionally pass back to the parent thread the results of commands and User Language programs.
See the Daemon class and Daemon methods pages for detailed information on Daemons and Daemon behaviors.
Why use a Daemon?
Daemons make it easy to capture command output and User Language output to Stringlist objects. They make it easy to keep server sizes low by splitting work between a parent and daemon. The use of Asynchronous daemons allows work to be discharged in "fire and forget" mode, where the Daemon completes a task while the parent thread moves on to other processes.
Variable Find Conditions
One problem often encountered in Model 204 User Language is that FIND conditions are bound at compile time. Variable input to a fixed number of conditions, with an unchanging set of field names, is handled well in ordinary User Language. But User Language has no clean mechanism to programmatically set up and execute dynamically generated FINDs.
Daemons handle this situation very elegantly. In the following program, a Daemon is instantiated, and a small program is built to FIND a set of records. The program is submitted to the Daemon in a StringList, and the resulting set of found records is returned to the parent thread in a SortedRecordSet object.
Begin %FindCriteria is string len 255 %Pazuzu is object Daemon %Sorted is object SortedRecordSet in file CUSTOMER %SubList is object stringList * Any of a variety of FIND conditions can be submitted to the Daemon. * In a full application, these conditions could be selected by the user through * a screen or browser interface. * %FindCriteria = 'RECTYPE = C ' * %FindCriteria = 'NICKNAME IS LIKE SI* ' %FindCriteria = 'RECTYPE = C AND LAST_MODIFIED=20101225' %SubList = new Text to %SubList Begin %BasicSet is object RecordSet in file CUSTOMER %Sorted is object SortedRecordSet in file CUSTOMER %BasicSet = New Find Records to %BasicSet {%FindCriteria} End Find Sort records in %BasicSet to %Sorted by NICKNAME %(daemon):returnObject(%Sorted) End End Text %Pazuzu = New %Pazuzu:open('CUSTOMER') %Pazuzu:run(%SubList,,%Sorted) * Process the returned sorted list For each record in %Sorted feoname: feo NAME print NICKNAME and NAME(occurrence in feoname) and TCPADDR(occurrence in feoname) End For End For End