On Oct 4, 2006, at 6:35 PM, Richard Gaskin wrote:
Well, one thing that leaps to mind immediately - stopping the
entire application freezing up when executing a lengthy shell
script or AppleScript.
The operating system is already threaded. This example doesn't
necessarily require Rev to give us the overhead and complexity of
running our own threads, merely to get notification of the
completion of an OS thread.
This is a good point. This kind of thing can also improve efficiency
even on single processor computers. On computers with multiple
processors, the improvement might be even better.
This can also apply invisibly within Revolution. With multiple
processors becoming popular, Rev might take care of some chores while
waiting for I/O. That is, even if a script blocks, Rev doesn't have
to. It might have some garbage collection, event preprocessing, or
whatever to do.
This trend might make it worthwhile for Rev to move some chores to
separate threads.
To some extent, applications that do file I/O and network I/O can
shift some work to another processor just by giving the task to the
system. This shift is not as much as I expected, perhaps because the
system is very efficient. However, a db might be a task with enough
work for one to see the work shifted to another processor. I image
some know how to reserve a processor.
A couple of my externals actually ran separate processes and
communicated with those. In those particular cases, that was not for
efficiency reasons, though.
A very advanced Revolution compiler might shuffle code around so some
work is done while "waiting" for a blocking operation. There might
be some clever look ahead or run ahead operations that can be done so
things look faster.
Many apps made with Rev are part of a tool set in which several are
used along with others. These exploit all processors (normally).
So, I would expect that the IDE and apps can get much of the benefit
of multiple processors and threading without threading actually being
a part of the Revolution (Transcript) language.
Dar
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
