Planning ahead for threads and more interactivity in rev apps
revdev at pdslabs.net
Thu Nov 8 13:03:04 EST 2007
One approach is to have a primary app which offloads 'blocking' or
time-consuming tasks to invisible secondary apps (also built with Rev)
via sockets. So the primary app would open a connection, tell the
secondary app what to do, and close the connection (or use a datagram).
Then PrimaryApp is free for other tasks while SecondaryApp does the
lookup. When SecondaryApp has some results, it opens a socket to
PrimaryApp and writes the results to it (or tells PrimaryApp about a new
data file containing the results, or...)
The use of socket communication keeps interactions message-based or
event-driven, which will keep PrimaryApp focused on managing server info
results rather than obtaining them. I believe that's what you want.
This approach is somewhat scalable too; you can have several invisible
SecondaryApps running if needed. (But that does add complexity to task
Anyway, food for thought...
xavier.bury at clearstream.com wrote:
> Hi everyone,
> In order to make an application more responsive, im thinking of
> implementing a kind of threading so that the application can still run
> while the GUI remains responsive. The application in question is a domain
> scanner and it scans some hundreds of servers which takes quite a while
> given the number of servers, their locations or type (phys. or virtual). I
> dont need this to go faster mind you but i dont want to go slower
> All i need is to be able to browse tabs and eventually change a setting or
> Problem is that mouse interception is not really working because of the
> intermittent shell calls and any mouseclick seems to get lost. Unless i
> want to click for 1-4 minutes and wait with the mousedown which i dont
> really fancy for anyone to suffer.
> Using "send" is also not a good idea because i use shell commands that may
> take different times to finish - some servers are vmware slow or are
> located in places like dubai or Prague may not respond too quickly...
> Problem with the send command is that if you ask it to send something in 5
> seconds and there is a process already running, the send will definitely
> not run in 5 seconds... And worse, it may prevent intercepting your
> I was thinking of a script that runs the shell, waits if mouseclick or
> something like that... But last thing i want is to make this complex code
> more complex... And im not sure the mouseclick will not be lost while the
> script runs.
> Something "interactive" is what I am looking for...
> Last but not least, i can't (or dont want to) manage more than 1 shell
> running at a time using a quick batch runner - meaning i'll have to manage
> interleaving and limiting processing load. The server has other functions
> and i can't monopolize the processors... Although this seems like my best
> Im just planning ahead this feature so all your ideas are welcome! Im sure
> many of us revvers are looking for a script like this at some point for
> applications that take time to process...
> Thanks in advance
> Clearstream Services S.A.
> 42 Avenue JF Kennedy, L-1855 Luxembourg
> Société anonyme is organised with limited liability
> in the Grand Duchy of Luxembourg R.C.S. Luxembourg B 60911.
> Visit us at http://www.clearstream.com
> IMPORTANT MESSAGE
> Internet communications are not secure and therefore Clearstream
> International does not accept legal responsibility for the contents
> of this message.
> The information contained in this e-mail is confidential and may be
> legally privileged. It is intended solely for the addressee. If you
> are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance
> on it, is prohibited and may be unlawful. Any views expressed in
> this e-mail are those of the individual sender, except where the
> sender specifically states them to be the views of Clearstream
> International or of any of its affiliates or subsidiaries.
> Legally required information for business correspondence/
> Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz:
> END OF DISCLAIMER
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the Use-livecode