Hello!
My few cents is that System Events is single threaded, and a major component for scripters, and should be avoid being bogged down at all costs, as it can lead to unstability, at least slow repsonses. Because what happens when the propertylist file is malformed for example?
So, when it comes to parsing of propertylist files, Iâd prefer xmllib of Satimage, or XPath queries.
Thatâs just me.
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).
Hello!
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.)
a simple test:
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.
Have I got it right?
Correct! You can run another instance of the application but AS doesnât support it.
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.
Hello!
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.
ASObjC Runner isnât a script runner in that sense â itâs an app, more like System Events.
Not necessarily. But a lot of stuff SE does, like file-related stuff, is time-consuming, and no amount of coding can make up for that.
Hi,
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. 
Thank you everybody !
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.
Hello!
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).
Hello!
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.
Hello!
Depending on what I am doing, the script menu tends to hang, or dialog boxes, that should have shown up, when scripts are executed, doesnât turn up.
My cureall for this phenomena is killing System Events, and that works!
But, Iâll keep a close look at the log files, and see if inaything turns up!
Today the script menu hung!
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.
What has
to do with t?
Kill SystemUIServer, not system events when this happens.
Hello.
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!
Cheers!