Cheapest Applescript Asynch IPC ever

Scripting Forums Code Exchange
,
#1

Hello.

There is no code here, you’ll find all the bash code you need on the net, by googling bash mkfifo example.

You can try this:

[code]Open two terminal windows, both with the same current directory.

Type cat pipe in the first.

Activate the second window.

Type and execute mkfifo pipe

Type ls-l >pipe and hit enter.

Look into the first window to see that now the result of the ls command has shown up in it.

Go back to the second window and “rm pipe”, we are done with the demonstration![/code]
The idea is to have two applets, that both executes a do shell script in a loop, you can use two pipes, that both has open the way you want, but one must of course write. You’ll use mkpipe for creating a communication-channel in the form of a pipe, not unlike those you create when you combine several shell-commands, but this pipe, has a pathname.

That way, you can have the two applets communicate with each other.

Of course this will make the applets, use more resources, but not that much, and you can write data into the writing side of the pipe, that the other applet will get on the reading side, and process.

I am not sure if this is any better, then sending messages, but at least it is cheaper, when it comes to apple events, and maybe it makes it easier to synchronize two processes. You’ll have to think out something up front, of course, a protocol, and the like, but at least it makes it possible to simulate a multi-threaded app.

The “reading app” doesn’t even have to block extensively while waiting for data, as the read command of bash has a timeout.

Maybe an Idea worth following.

Edit

One thing I haven’t tested is if it is possible to read and write to a pipe directly with Applescripts read and write commands, if this works, then it makes the usag of pipes between apps/scripts even simpler! :slight_smile:

And this (the first approach with shell), can of course be used in combination with FSEvents (Launchd Agents), and you get synchron communication between two applets if you use two pipes, one for incoming, one for outgoing.

#2

I haven’t seen this post but I’m familiar with named pipes (fifo) and therefor this side note: You should be aware that this can only be used in AppleScript between two different instances of AppleScript. AppleScript is single threaded and do shell scripts or read and write commands, even between two documents in script editor, are queued instead of running on a different thread. This means that you’re not able to read an write a named pipe simultaneously withing the same instance of AppleScript like in an local server client.

#3

Hello.

But it would work between an applet/or script in one end, and something else in the other end. :slight_smile: (LIke a bash process of somesort)

:confused: But it would be natural to think that I should get several instances of AS, when I have different compiled applets. At least if I use AppleScript runner to execute scripts from within an Applet.

Well, there are of course ways to circumvent this problem and that would be to feed by a shell script, and read by AppleScript, that way you wouldn’t block anything, because of single threadedness. :slight_smile:

Edit

It beats me that using the run script construct, sets up a new AppleScript Environment, now I wonder if that includes or implicates forking a new instance of AppleScript.

#4

it was an side note and won’t take away anything from what I’ve said.

You could also have a script, save it is an application and stay open. This can be used for IPC too and don’t have the drawback because the communication itself is an new instance of AppleScript. for the record: Stay open AppleScripts are scriptable application and can act as an communication server. Which makes it real async too (callback system) which is using named pipes not (polling).

Edit: But in general for communication between two processes named pipes are good for IPC simulation. I’m just showing one of it’s limitations. An real IPC would have no problems communication within the same process :slight_smile:

#5

There are of course levels of IPC. but Asynch communication is as real as everything else, it is just more primitive.

And by my terms of a process, it contains at least one thread, maybe many, and named pipes can be used to communicate between threads, so no limitiations, the limit here is really AppleScript, but that is ok, you don’t need named pipes for IPC between a single AppleScript anyway. :slight_smile:

#6

Pipes or named pipes are (party) synchronous. Asynchronous code is code that’s been dispatched and designed to run in an non-blocking mode. You read an pipe, the kernel is putting your system call on hold until something is written to the pipe if it’s empty. Because your read command is blocked it can’t be asynchronous. As in a perspective between two AppleScript instances were one’s reading and one’s writing I would say it’s still synchronous because the action will only take when one process writes and the other reads in an synchronize way. The other way around it is asynchronous, first writing and reading later, but that’s not how you’re going to use pipes in this case.

It’s doesn’t make it work different or worse knowing this. Just saying that it doesn’t work asynchronous.

#7

We are into the things we do about putting different things into terms again. :slight_smile:

What I mean by synchronicity or asynchronicity, (pwhew) is that the communication can occur at random points in time, whether the receiving app/thread is blocked while it waits is not anything I consider here. Now, traffic over an usb port, that is synchronous (why do they have to add ous, when synchron is enough?), since it will have to happen within a timeframe before the operation times out.

I hope this clear things up a bit, polling for an event, doesn’t make it synchronous, the way I see it, the process can really go on, and do other stuff, as long as there weren’t any input there, (at least in theory, and maybe in another thread, but I think I can make that happen in the shell as well, as with a select call, or poll, in C) The reader process polls for input, but it doesn’t wait for that to happen within a timeframe.

In the end at the process level, the communication is asynchronous, and I think you can have a named pipe between machines, and then what blocks or not, becomes less interesting at the system level.

It is good to have you around to discuss stuff with DJ! I hope the weather is as nice at your place, as it is here!

#8

It is indeed, and interesting topic from wikipedia. Thanks for your input an I really apreciate it and we’ll learn new stuff every day. I’m going to disconnect my office from electric source because after more than a week of good weather a very heavy thunderstorm is coming. So I’ll see you after the storm:) (enjoy your weather!)

#9

Well, have a nice one, I shouldn’t be here either, I have mountains of stuff to do.

I just want to add, that I don’t need to use cat in the other end, I can use read, and make it just fail if there aren’t any input there, and then it will become perfectly asynchronous, as it won’t block.

I hope the Thunder passes by, without any havocs.

See you!