Revolution and Task (handler) Overlap

[David Vaughan]

>
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?