Threading

[SirWobbyTheFirst]

Hey everyone, this has probably popped up before but a quick search of the forums doesn't seem to show anything.

Would it be possible to get Threads implemented in LiveCode sometime in the future, it might not sound important for some put spawning off work to actual threads on the processor as opposed to the light weight threads (AKA Fibres) that the send command uses would be very useful for doing stuff like copying files or waiting on downloads while keeping the GUI active. I've used threads in Java and C# and I honestly want to kiss the person who thought up the concept because they are hella useful.

I tried a little workaround by using the send command to execute a file copy command on Windows and the moment the file started copying the GUI locked up and had I not Ctrl+C'd the Command Prompt window, I probably would have been waiting a good 30 minutes. If it cannot be implemented in the engine, could it not possibly be implemented using an external, I would try myself but the whole reason I came to LiveCode was to stay away from the likes of C and C++ (Even now, the sheer sight of them makes me pull my legs up and rock back and forward again) and we can't really use any other language.

[shaosean]

There was a sneak peek version of the externals that allowed for threads, but Rev has never released it and not certain if the engine would support it. There seems to be a way to spawn off new processes, but there is no real documentation on it other than a quick little sample in the release notes and it does not explain how to actually set anything up to do it.

[SirWobbyTheFirst]

Ah crap.

I'm currently looking up C# to C++ converters in the hope I might be able to put my C# skills to use and write a library which can spawn additional threads then convert it to a C++ based library but whilst I've found an application to do such a thing, again the C++ syntax has got me weeping at how scary it is (Plus having done a little bit of C++ in the past, I am not entirely sure whether the code looks right). ¬_¬

[shaosean]

Some of us having been waiting a decade for an updated externals interface, and Rev has teased with them, but nothing has ever been released. If I am remembering correctly you can do threads in the current externals interface, just you are responsible for pretty much everything. I think Andre did an external with threads, let me look through my files tonight for you.

[SirWobbyTheFirst]

Thanks man, I appreciate it.

[shaosean]

Actually was thinking of this while doing the dishes (blargh) and think I might be able to put together a quick proof of concept completely in Rev so you will actually being using separate processes (which will allow the OS to spread the work across multiple CPUs and cores)

[SirWobbyTheFirst]

Whichever method is best, although if you mean by using Open Process and Close Process, I would very much like to see some source code as I requested information on using those commands a while back and got told to use sockets instead which was a pain because the documentation for Open, Close, Read and Write Process is a bit limiting with regards to what to actually write to a process.

[shaosean]

yeah, i was thinking of using the processes method as they apparently made some changes in one of the livecode versions.. and source code will be released so you can play with it..

[SirWobbyTheFirst]

Thanks man, I appreciate it.

[shaosean]

Here is the external that Andre wrote a few years back.. Tried to find a live link for it, but it seems to be gone now.. I believe this should be the original files, but I pulled it from my working directory and not from archives so buyer be warned In this external he offloads the playing of a MOD file to another thread.. I have not run the external nor tried to compile it so YMMV but it does show it is (was?) possible to do..

http://shaosean.tk/runrev/third_party/revmikmod.zip

[SirWobbyTheFirst]

Thank you shaosean, I will have a look as soon as I get back from my session at Uni, again thank you.

[BvG]

An easy way to do this is to have two rev stacks. One is your main GUI, the other has only a "startup" handler that ends with "quit". You then start the "child process" stack with launch. Altho horrible inefficient, this actually works and is easy to implement, and should yield good results if you have a very long processing time. For feedback, you could write a file into a hidden position, and check if that file exist using send in time. For example (code untested):

Main program:

Code: Select all

local tooLongCounter

on mouseUp
  launch "/Documents/myChildProcess.rev" with "/Applications/MyProgram.app"
  send "checkForFile" && (specialfolderpath("Temporary") & "processDone.txt") to me in 10 seconds
end mouseUp

on checkForFile theFile
  add one to tooLongCounter
  if there is a file theFile then
    answer "the process is done, and the result was:" & return & url ("file:" & theFile)
  else
    if tooLongCounter >= 30 then
      answer "something went wrong with the child process, it didn't finish after 5 minutes."
    else
      send "checkForFile" && theFile to me in 10 seconds
    end if
  end if
end checkForFile

child Process:

Code: Select all

on startup
  hide this stack
  wait 200 seconds
  put "done doing nothing useful" into url ("file:" & specialfolderpath("temporary") & "processDone.txt")
  quit
end startup

[shaosean]

but does it actually run as a separate thread/process? will the GUI remain responsive when doing lots of these?

[BvG]

of course, because you use a different standalone, not the one that contains the gui

[sturgis]

I actually use a web server for this. Especially since lc server works so well.

If its a process that can be broken into chunks do a
load whateverurlpassingargs with message "processtheresults"

If order matters, one of the (GET) params sent to the web server designates the position of the results. Usually I just do this on the same local machine but it could easily be spread out to multiple machines of course.

This unfortunately only works for projects that are completely controlled of course. Though I guess a web server with the proper cgi scripts to handle things could be bundled with the binary. Either way though, for certain projects this method works swimmingly.