LiveCode Forums.

Greetings,

I have some lengthy DB and Internet operations which doesn't required to be finished before the user can do something else whithin in his visual interface.

What is the best practise advise to create this type of "multitasking" or multithreading"? Does anyone have a code examples or hints/advice for an how-to?

Thanks,

Frank

I've used the shell() function on Macs to do various commands with nohup, which lets the shell function return immediately while it continues to do whatever it does. If you can use the curl command for your "internet operations", then this might work for you.

But if you want to run a lot of Revolution code in the background, this won't be of much help.

I'm not sure if this is something you've already ruled out, but the 'Load URL...' message can take an additional 'with message theNameOfSomeHandlerHere'. Of course, it is still Rev's libURL library that is doing the work, but it should mean that you can get on with something without having to wait for the 'Load URL...' to return.

See the documentation under 'Load URL' to learn more about using callbacks.

RevQueryDatabase does not have this callbacks feature. However, are you sure your database is properly tuned (indexes on the appropriate columns make a phenomenal difference in rdbms queries, so also does a sufficiently large RAM cache in the database).

If none of this works you could try more elaborate techniques using callbacks with handlers that make the queries for you, and using 'send in time' to check whether a query has returned.

Please elaborate with more details (what are the internet calls doing, what is the database configuration, etc) and someone else might have additional suggestions.

Hi,

my question is: what to do in situations in which you know you need background processes that are blocking user activities, because they are taking so much time/resources; Revolution has no multi-threading capabilities. Which is pretty bad

I remember that i was using an example from the tutorial (Basic: Internet Images):http://runrev.com/developers/tutorials/ ... et-images/ The internet communication has even slowed down the refreshing of Revolutions' IDE windows -- I reported this as a bug, but then I understood, that this is due to the principle weakness (!!!) of not having multi-threading capabilities.

This is pretty scary, if activities such as: file system, db or internet background processes could have such a huge impact on the user experience so even the refreshing of the interfaces could take seconds. The size of tasks are not always in the controil of the developer .. and sometime it is simply a precautions to put tasks into a thread in order to avoid these weird side-effects

I know I will have, beside internet activities, large file-system and DB activities which could take 20sec to 1 minute to be finished: I was considering to create a progress bar control from which these activities are initiated and could be used to inform the user that there are is no interactivity. thios progress bar control could segment these activities in smaller chunks, but lets be honest: this program behavior for these type of activities looks a little bit antique and embarrassing.

Therefore I thought of the following solution: Putting these activities in separate programs with no visual interfaces, which are initiated by the main program and closed after they are done. Because these processes might not responding to requests on info of their current status, progress info could be written into and accessed from a shared SQLite DB.

This approach should work and should be a sound workaround for Revolutions' deficit of having no multi-threading capabilities.

Maybe this could be turned into a more generic solution for dealing with Revolution limiting multi-threading capabilities.

Any Comments?

Best,

Frank

Hi Frank,

As a Java-developer, I understand your desire for multithreading capabilities in Revolution - however, they open up a huge can of worms for developers who mostly don't want to be bothered with low-level details. And while 'synchronized' is a lovely Java-keyword and the concurrency package has a whole bunch of classes to help, you can still get yourself into plenty of trouble.

That said, I would love it if more parts of Revolution followed the 'callback' paradigm that we have for socket communication. In the meantime, you can use a 'send in time' construct to allow user events to occur and the screen to redraw.

And for database access, my trick is to not use the 'revDataFromQuery' function to get all the data in one go, but use the 'revQueryDatabase' function instead to get a cursor, and then fetch the records + update the table field in blocks of 20 records using a 'send in time' construct.

Revolution is usually very fast, but smart developers take care of those situations where things take a little longer...

Jan Schenkel.

Well, first of all, I'm not sure what your precise problem is. I just tried the internet tutorial you mentioned, and there was no problem for me - it's lightning fast, and there is no indication of any problem with the IDE slowing down. Maybe you are on a really slow internet connection (I'm on ADSL, so nothing really fast at this end). Maybe you have some other problem with your computer or with something else you have running in Rev. (For the record, I just tried the tutorial on an extremely cheap laptop I got that came with Vista pre-installed - I'd imagine any other computer purchased in the last 12 months would be faster than this).

Furthermore, I don't know what you are comparing Rev to. The last couple of days I had to use a Java program (from IBM no less), and every time I had to return to the program from looking something up in another window, the Java program would take as much as 30 seconds just to re-draw the buttons on the screen (only a few buttons and a few fields). Rev only behaves that way when something is seriously out of whack in the IDE (e.g. an endless loop, or a massive number of errors being fired off).

Jan gives you some good advice about using cursors. There are also callbacks, and the use of 'send in time'. My advice would be to start identifying some concrete issues you are having, and see if they are really issues with Rev or something else. Then start asking for advice in those concrete situations. I think you are going to find that a more productive route. If you are going to use Rev, you will need to think more in terms of an event-handling paradigm than a threading paradigm.

Your suggestion of using helper programs is not unheard of, but that route is something I would only consider when all else fails. I think that you need to find out why you are seeing such poor performance from e.g. the internet tutorial.

Mark Smith has just announced the release of this here:

http://futsoft.futilism.com/revolutionstuff.html

This might be of use to you in dealing with your blocking issues.

Bernard