Open Process

[makeshyft]

Hi there Livecoders,

Wondering if anyone cna point me in the direction of getting 2 stacks (standalones) to communicate using the open process. How can I get a stack to return data to the process that called it?

So far, one stack would contain open process..... for reading...... its the other stack that i don't know where to start with..... if i put the functions into openstack for example...how do i return the result to the other stack?...and is the data in "the result" in the original stack?

Thank you for any help

[[-hh]]

A good point to start is with Bjoernke's stacks:
Simple socket Server and Simple socket Client. You can work with them locally too.

[FourthWorld]

Do they need to be separate standalones? What platform(s) is this for?

[[-hh]]

I tested Björnke's stacks to run very well, but never made standalones out of them.
The stacks are, as I wrote, a real good point to start.

Your question targets more the next step. May be, 'makeshyft' is already beyond that step with his project. We will see.

[makeshyft]

Hi everyone,

As far as I know yes they must be standalones, I know that the livecode engine can open .rev files and run any handler in them...however if i had my choice i would definately run standalones in this project in particular. I also would like to thread some operations and would like to be able to send commands to another process. The platforms will be the desktop.

I am in the beginning stages of building of this particular projects, so i'm on the base layer, designing the main architecture of how things should run. Given that livecode is a single thread application, i'm looking at ways of getting around this limitation (if needed). hence the research on multiple processes.

I don't even know if the open process is a blocking operation or not..... just couldn't find any info how to have a standalone return data to another standalone that called it using open process...

I will check out those example stacks and see if that gets the job done.

Thanks everyone for your input thus far.

[makeshyft]

The sample stacks are indeed useful in getting 2 stacks to communicate... thank you. still interest in seeing if open process can be a way to do the same thing so as to not use tcp/ip.

[FourthWorld]

For the pursuit of multiprocessing it sounds like you're on the right track.

"open process <appPath> for neither" will prevent the synchronous dependency in the calling process either reading or writing to the process, effectively launching it and then resuming normal control internally.

To launch a LiveCode standalone facelessly add "-ui" to the command line args, e.g.:

Code: Select all

open process "/home/user/app -ui" for neither

Within each launched worker process you can use the "accept connections" command to open a local port for listening, and then communicate with it from the master app that launched it in the manner illustrated by Bjornke's stack, or the well documented example here:
http://lessons.livecode.com/m/4071/l/12 ... ng-sockets

Instead of the external machine IP address you can use the local loopback address (likely something like 127.0.0.1). It will still be using sockets, but need not require any external networking.

The loopback address will vary depending on the system's configuration, but you should be able to obtain it using:

Code: Select all

get hostnameToAddress("localHost")

Alternatively, there may be times when communicating through files can be a useful alternative to sockets. This is not as slow as it may sound, and when using Linux it can be quite efficient by taking advantage of the already-available RAM-disk-like special directory /run/shm/.

I'm always impressed by workloads significant enough to require multiprocessing, so if you don't mind my asking what are you building?

[makeshyft]

Hi Richard, thanks for all the very useful hints...

In short, I am building a resource and contribution management system (project management) called the Contribution(+)Engine. Down the line, the core of this will software will become something else..... so its a 2 in 1 kind of project, and I have to take both into consideration.

I don;t have specific examples of when multi-threaded processing will be useful to me. its too early for that. I feel confident though that it is important to have access to the the full processing power of the system, which is why i want to take it into consideration right from the beginning and build the base layer correctly.

I'm having a great time using Livecode to build this thing from scratch. When I started the UMP I had no idea how to use Livecode .... and literally started working on the UMP right away, never building anything else. So being more experienced now makes things a lot more fun.

Thanks again for your help.

[FourthWorld]

Ah, the UMP. I've only seen that one brief demo at Peet's so I can't speak to the applicability of multiprocessing for the tasks it supports. But I would caution against spending too much time on multiprocessing up front; well-factored code may provide opportunities to break it up among multiple processes later on, but managing multiprocessing has several limitations:

- Race conditions become a concern, requiring very careful management of data locks on shared resources.
- Nothing in computing is a free ride: more processes can mean more concurrent tasks, but at the cost of more RAM.
- If a process depends on sequencing output from multiple processes, in which the task isn't complete until all outsourced parts are complete, then the system as a whole can never be faster than the inherent speed of any single process (Amdahl's Law).
- Setting up and managing multiple processes eats developer time.

For many server tasks multiprocessing is essential, but there the concurrency plays well with the nature of the task, since each process can communicate with a separate client using separate (or reasonably separated) resources.

In a single-user system there can still be cases where multiprocessing can be useful, but far fewer of them and many requiring mindfulness of the tradeoffs to determine applicability for a given task.

A talk I found useful as I started exploring concurrency is this one from Google's Rob Pike, "Concurrency Is Not Parallelism":
https://www.youtube.com/watch?v=cN_DpYBzKso

[makeshyft]

From what I know at this point I am more more interested in concurrency rather than parallelism ..which is why your stack on timed messages was so helpful to me. But I did also want to find a way to use more than one processor core if needed.

I understand completely what you mean about eating dev time trying to achieve something that isn't all that useful. I don't think I'm going all out here, just want a simple way to offload some tasks that would not produce race conditions. I think the content of this thread alone has enough to achieve the possibility of that functionality.

There are tons of loops in the UMP, because we are processing users, statements,responses,etc....but there is nothing in it that would benefit from concurrency, except maybe to keep the UI from freezing on processor demanding loops, at which point I just use wait 0 with messages.

The video link is very useful.