Revolution and Task (handler) Overlap
drvaughan55 at mac.com
Sat Feb 9 21:42:01 EST 2002
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.
> So once you send a message, that message is handled next regardless of
> 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
>>> engine is multithreaded in all cases with calls back to the engine
>>> 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
> way for all platforms?
More information about the Use-livecode