Revolution and Task (handler) Overlap
drvaughan55 at mac.com
Sun Feb 10 18:30:01 EST 2002
Sorry about the delay in responding but I live in another time zone.
On Sunday, February 10, 2002, at 05:07 , Gary Dennis wrote:
> I want to find a way to use this product. Is it
> possible to have the pre-processor you suggest executed from within the
> stack as a separate task or is it strictly stack = task for REV?
If I interpret you correctly, then from Scott's writing and my testing,
Rev is single-threaded and executes one task at a time in a stack. I
infer that this also applies to a collection of main stack and
sub-stacks. There is message passing through that chain but not
independent tasking. Running multiple tasks on one processor gains us
nothing for the overhead so, to maximise speed, we need to run on
multiple processors (two boxes? an OSX or NT multi-processor?). I am
making two assumptions here
1: Your testing as previously discussed with a single stack on a single
processor system proves not to give enough speed; and
2: The initial filtering of messages is both relatively simple in
process (a one or two-pass text filter) and effective (the result will
be a "significant" reduction in message volume required for further
processing). This assumption is based on your early reference to needing
high priority messages.
> What I am
> seeking is the ability to control the task you suggest and the other
> that will be used to display and query from the same UI. I don't mind
> suggestion of some exotic programming approach as long as control and
> reliability is not compromised.
> Is that possible with REV?
My broad design would be to create a faceless stack (maybe with a quit
button) for most efficient input filtering and distribution of the
reduced data sets to management stacks, which provide the UI and
whatever management functionality you are selling. These could be run on
one box for testing and two for maximum performance, or one dedicated
input filter and up to 20 management boxes I think you mentioned.
The faceless stack would set socketTimeOutInterval to something less
than its default 10 seconds (!) - start testing around
100-200milliseconds - and do a straight read with no ending condition
other than the timeout, after which post-processing and data
distribution occurs before return to the socket read. Doing the socket
read with a "send in..." message might make data reading real time
within the main filtering loop and together with the
socketTimeOutInterval gives you effective tuning of priorities(*see Note
below). Data is then distributed through TCP connections to any
connected client system. That is, the faceless stack operates as a
socket server (accept command) so a variable number of clients are
If parameters need to be varied in the input filter (and this should be
kept as simple as possible) then a separate socket can be used to accept
parameter modifications to the filter, again as a server socket because
this enables Rev to react to a connection by a client rather than having
to waste time polling the port.
*Note: Come to think of it, these options could make the system remotely
tunable or even self-learning with respect to frequency and duration of
socket reads and thus priority assigned to reading and processing.
Hope this is helpful and not teaching you to suck eggs!
DVK Consult Pty Ltd
> Thanks and Best Regards
More information about the use-livecode