The AppleScript language doesn’t support the creation or use of multiple threads; you’d need to use some other language for that.
Have you profiled your code to see where the performance bottlenecks are? I don’t think using multiple threads will make your app go faster (why do you think they would?); might make it more responsive while files are being deleted, but the actual file deletion bit will take as long as it takes.
BTW, your do shell script (“rm -R '” & theLocation & “'”) is completely unsafe; use do shell script ("rm -R " as Unicode text & quoted form of theLocation)
Just how unresponsive is it anyway? If it’s only a few seconds delay, or if there’s really not much other useful work the user can be doing meantime, then I’d suggest just living with it. Studio’s hardly an ideal choice for writing sophisticated high-performance apps anyway.
Assuming you do decide to pursue it further, have you profiled your app to see where the performance problems are? That’s the very first thing to do - you can’t provide a proper solution until you’ve worked out what the problem actually is. It may be that you’ve a lousy algorithm somewhere that’s causing it to take far longer than it actually needs to, in which case you should fix that first. Or it might be that the GUI code is just naturally slow, in which case threads won’t help you.
If it is the file deletion stuff that’s the major time consumer then that’s something that could be offloaded to a second thread/process to avoid blocking your main thread. Since you’re working in AppleScript the simplest thing would be to spawn a background process via ‘do shell script’ that handles all the file deletions as a single batch operation, with progress/completion being communicated back to the main process one way or another. It’ll be fairly clumsy however you do it; neither AppleScript nor Studio make this sort of thing simple or convenient.
Since filesystem deletions can also be handled individually, another option is to handle file deletions one at a time from the main event loop. Stick pending deletions into a queue, then have the application’s idle handler process these queued jobs one at a time. That’ll allow you to do everything from the main thread without blocking other GUI events for a lengthy period. The only disadvantage IIRC is that Studio’s idle handler has a minimum delay of 1 sec; ideally you’d want something like 1/10 sec so deletions are handled fairly snappily. Still, you could compromise by deleting several files at a time; the GUI should remain moderately responsive and file deletion will progress at a reasonable rate.