Because what happens when the propertylist file is malformed for example?
A timeout will occur, restart the application or you will receive an error and nothing is wrong.
The problem you describe applies for scripting additions not for applications. Even knowing that OSAX allows (since 10.6) thread safe handlers doesn’t mean they are. They all respond to events in the main queue, so if one event hangs in XMLLib the rest will so as well.
For example you can’t pipe data from one script to another using shell script, because do shell script in script 1 is waiting for data, script 2 can’t even start because an event in script 1 is blocking your script. You can only make it useful when you completely run two different applications (file must be saved as application).
Then it seems to me like XPath is the way to go, when parsing large propertylist files.
Are you saying, that if any OSAX hangs for some reason, then all other applevents in that queue will be put on hold, until that hang, is resolved? -I don’t know how it is resolved, but I guess it is removed when a timeout occurs, am I right?
Because this is interesting I always thought the the eventqueue flowed freely, but that if something kept System Events from responding, then only those events waiting for System Events would have to wait.
With your explanation, I now think that if something goes awry towards a a scripting addition, on the eventqueue, then the whole eventqueue is put on hold.
Is that right? (And I haven’t come around to reading the System Overview yet.)
Terminal (multi threading):
create a named pipe (mkfifo)
try to print the file (it seems like nothing happens)
open a second window and echo some data to the named pipe
The result is that you see the echoed data in window 2 will be printed in the first window.
AppleScript (single threaded)
using the same pipe
try to get data from the named pipe (do shell script “cat …”)
open a second window in script editor
Now send some data to the named pipe (do shell script “echo blahblah > …”)
The result is that the event in the second window waits till the first event is ready and can continue.
This seems weird but isn’t. Both scripts have the same current application, which means have the same event queue even if it runs in a different thread. Osax events are (must) send to the current application which means that your own application starts to hang. I think you’re better off when an external application is hanging that your own; you have no control.
Ok!
So if I have several scripts running, (hypothetically) and they all use say AppleScript Runner, then they will be processed in a single thread.
But if I use different script runners, then they may process in parallell. But System Events, is an application, so there is the next bottleneck, as it doesn’t spawn a process for each thread, but handles all in one fifo queue.
It’s not quite that simple. For example, ASObjC Runner receives commands on the main thread, but passes them for processing to a background thread. So if a script sends a command to Runner, another script can send a second command while the first one is being processed.
Does that hold for just ASObjC Runner or is it applicable to other Script Runners as well? like AppleScript Runner, and osascript.
And I guess that holds for ASObjC Runner and maybe the others, as long as there isn’t any shared resource involved, System Events would be such a resource, that they would have to line up and wait for, as System Events is single threaded.
Or the threads ends up in System Events fifo queue should System Events detect a resource conflict?
I guess it holds that System Events is single threaded. That would be in accordance with murphy’s laws.
so far interesting discussion. Some parts are more advanced, hehehe but I understand most of it. Yes my example is shorter. I have maybe 30 products for “SoftURL” and it will still grow. For sure multithread will be needed maybe in the future. I did not got the time to use all the tricks and codes you gave me but it seems everything I need so far. If you have more to share to speed up the thing with “vanilla code”, I’m open.
Who says that SE is single threaded, like I said and proved with my OSAX example (do shell script is no part of SE, but part of an OSAX) that your cons about SE applies for OSAX. OSAX allows since 10.6 multi threading (thread safe) but almost everything you find in an OSAX is not thread-safe because it can’t be threaded, like do shell script. Then my second point was that when an external application as SE hangs, you can restart it with your script and try again or give the end-user a warning. When something goes wrong in an OSAX you have to restart the current application which is your script running as application or script editor.
There are however some pros for using OSAX, they are indeed faster (the parenting chain of events is shorter;when you use it right). Also you can embed by creating a folder named ‘Scripting Additions’ inside the resources of your application; this way the end user doesn’t have to worry about the right version of the osax or if the osax is installed or not. OSAX is binded to the current application, no separate process needed. Because a new instance of OSAX is binded to every current application, different (standalone) scripts don’t interfere with each other. So in short the most advantages of an OSAX only applies when you save your script as an application and not running it by an script editor/runner.
it was actually you who said it in post #4 in the article AppleScript/Applescript-Studio: Background Code by B. Boertien
That can be found Here
That is my “con” against System Events,being used a as a parser of property list files, espcecially at endusers machines, as it is such a central part, when it comes to scripting, that it is a good idea to not use it as a “work horse” for such purposes, as it may hang, and leave the user in peril.
And it isn’t so, that it is just for some user to restart System Events, there are a lot of users out there, having no idea of what System Events is.
I am even sure, that there are people here, that doesn’t have such a little snippet in their script menu:
#/bin/bash
ps -Al | grep System\ Events | head -n 1 | grep grep || killall System\ Events
I do agree fully with you on the purposefullness of Osax’s.
Edit:
And if memory serves me right, I believe you have to drop the space in the the name Application Support within the resources folder, but spell it like ApplicationSupport, in one single word, for it to work properly
That’s certainly true, all else being equal. But there have been plenty of cases, including in commands in Standard Additions, where what is presumably the slowness of the code makes this point rather academic. I haven’t looked recently, but the round command used to be a good example of this.
How ironic :D. No, what I said there was true in that context. I wasn’t talking about System Events in general only some part inside SE. The part I was talking about applies for every application in Mac OS X and every OSAX.
I’m not sure if I understand the ‘hanging’ part to be a reason not to use SE and ever will be or if it applies for me. You have to be realistic, when does SE hangs? I’m using SE for 10 years now without any problems (including hundreds of workstations). Also SE can read compiled/binary and xml plist files because a plist doesn’t need to be XML formatted (said because this topic becomes more general).
Lets qualify this a litte more I’am talking about parsing plist files, where you want to exctract more than a couple of keys, maybe 50-100 or so, maybe more.
Then I want to rely on another tool. I use for instance the script menu, and it really bothers me, if that piece stops working because of some action in the system elsewhere, either because it has crashed, or because it is busy.
I am not talking about the plist file of an applett, with 5 entries more of something like the Safari’s plist.file but not that big either, if you get my drift. and if then is any errors in that piece, then things will become unstable.
I am pretty damn sure errors into something like that, with nested structures will keep System Events occupied for a while.
And I am not talking about what happens on my own machine, because I live well with it, I know how to restart System Events. I am talking about distributing such a solution to end users really, and the OP in this post, well he did show as a plist file with errors in.
Under such circumstances, I’d rather use another tool, like XPath, or an external Osax, like Xmllib than System Events for the sake of overall stability.
And that is just me, and it is no big deal really, but that is how I judge matters. Even if System Events was 10 times faster, I’d go for something that keeps the System Events sane, and available, to all of those scripts that are relying on it to work.
I am also very much into using what is already there, but this is one of the exceptions to the rule.
Up to 5000 can still be done within a second, unless you have a pre-historic machine :D. Then plist files aren’t designed to store gigs of data in it. It is an archived/unserialized NSDictionary object.
Mmmm, there is a paradox: I don’t want to rely on tools I want to use script menu (which becomes a tool). Who is the event listener here: AppleScript runner. What happens if I want to run a second script: It will be completely ignored, at least SE puts you in a queue.
The same happens as every parser will do; it will throw an error, nothing hangs or gets unexpected results.
Have you even tried this yourself? Nothing weird will happen, system events doesn’t wait until the error is accepted or anything.
Did he? my system didn’t had any problems with it.
Of course your choice is free because I prefer to use do shell commands for file handling over Finder and System events, so I choose osax over external applications in that context for some reasons. But I started to respond to your post not to tell you that you shouldn’t use osax or something else, I started responding because I (still) think that the arguments aren’t valid. When you say if it’s better for application distributing, XML support, performance, etc… I would have agreed. System events is quite primitive and the biggest advantage is that it doesn’t matter how the plist format is, it supports binary and xml property list files. Another reason is that system events serializes the data to records while other solutions won’t. That makes it also very easy to handle and transport to other tell blocks, using it in another context/focus which other solutions can’t either. That is for me a good reason to use SE.
If you consider to keep saying that SE starts hanging in your next post(s): please give an example when SE hangs because it seems impossible. The parser (for binary as xml based formats) is good code and it has to be because it uses the cocoa’s property list parser (NSDictionary serializer/archiver) ; the same parser every cocoa application uses.
The reason: Probably a dialog, where I didn’t “activate” up front! Annoying! :mad:
I found it, as I saw the darn dialog when I hid the other apps. And it didn’t help kill System Events! In all fairness.
But parsing big propertylist files with applescript, is something that should be avoided after all. You can read about that under “internal table overflow” at stack overflow.
It was about my previous rants about the scriptmenu, and system events!
It has to do with the fact, that it isn’t always System Events that is at err, when that happens.
And that was from one of the blocks I didn’t use SystemUIServer, but using SystemUIServer, wasn’t the point, the point is I believe, not activating me, before displaying the dialog!
I always thought the the eventqueue flowed freely, but that if something kept System Events from responding, then only those events waiting for System Events would have to wait.
