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 > _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
