Revolution and Task (handler) Overlap

[David Vaughan]

Gary

Sorry about the delay in responding but I live in another time zone.

On Sunday, February 10, 2002, at 05:07 , Gary Dennis wrote:

snip
> I want to find a way to use this product.  Is it
> possible to have the pre-processor you suggest executed from within the 
> same
> 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 
> task
> that will be used to display and query from the same UI.  I don't mind 
> the
> 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 
efficiently connectable.

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!

regards
David Vaughan
DVK Consult Pty Ltd

>
> Thanks and Best Regards
>