Revolution and Task (handler) Overlap

[Gary Dennis]

David,

I appreciate your candid informative  response. I love this product (How
could you not?).  However those occasions on which we have gotten our butts
kicked the highest have been because we didn't have good answers (for our
products) to questions like I have been asking about Revolution. "Still
Unhappy" is not completely accurate since I have been so happy that I have
given practically everyone in our Engineering group a demonstration on the
product.

Because I am so impressed, 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?  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?

Thanks and Best Regards

----- Original Message -----
From: "David Vaughan" <drvaughan55 at mac.com>
To: <use-revolution at lists.runrev.com>
Sent: Saturday, February 09, 2002 8:38 PM
Subject: Re: Revolution and Task (handler) Overlap


>
Gary

In relation to your subset of queries below, my tests show that Rev
message handlers are sequenced (invariant) and blocking. The socket read
has a variety of escapes of course (a string, a character count, a
timeout) but appears technically to be a blocking read. So Björnke may
be in luck with his free licence, or you may contemplate some redesign
rather than assuming that blocking = the end of programming life as we
know it. For 25KB/s of data potentially receivable I would in any case
consider constructing a small preprocessor to filter the high priority
messages (which seems to be your high volume requirement) and pass these
to Rev targets for further manipulation and presentation. This should
break your basic speed bottleneck while maintaining the bulk of your
application in a productive environment. It would not be the first nor
will be the last such approach in computing.

If at this point you are still unhappy with Rev then, recollecting that
you were kind enough to note my earlier  jocular Latin note,
de gustibus non disputandum.
:-)

cheers
David

> So once you send a message, that message is handled next regardless of
> other
> messages that may be received?
>>>

>>> Question 2.  Does this approach give you any true overlap in the
>>> receive-process cycle?  It appeared to do so.  My assumption is that
>>> the
>>> engine is multithreaded in all cases with calls back to the engine
> providing
>>> the opportunity for handler overlap.
>
> Let me get this straight. You simply push the message to the end of the
> queue so that...
>
>
> read from socket x ... messagereceived
> on messagereceived s,data
>      send " messageprocessor  data"
>
>      read from socket s .... messagereceived
> end messagereceiver
>
> causes the sent message  put to be pushed to the back of the queue
> until the
> read is satisfied?  Is the read truly a blocking read?   If so, is it
> that
> way for all platforms?

_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution