"Multithreading" - ie multiple scripts in a prim

OK, so I've got different prims that communicate with each other in a kind of master/slaves setup; the master controls the slaves and also serves as a UI; the slaves do the work they're told and report back when it's done. Communication is through llRegionSay(), since they might physically be a considerable distance apart. All's working reasonably well so far, but there's a lot more functionality to be added.

Now, I'd considered splitting the two scripts (master and slave) by function, scripts within each prim communicating with one another through link messages. This would simplify things a great deal in a lot of ways.

For example, they use a timed PING/PONG type of communication between master and slave just for each to ensure the other's there when other comms are quiet, and to deal properly with cases where one or other dies, crashes, is taken into inventory, or whatever else might happen. Also, the core functionality calls for state changes depending on what modes they're in. Currently, each state does its own job as well as handling PING/PONG communications. If a separate script could be triggered to do the PINGing and PONGing, which only communicates back if something goes wrong, that would certainly make the code smaller, faster and easier to maintain.

There are a couple of other tasks that I believe could be greatly simplified if they had their own scripts running separately.

Now, so far so good, until I came across a page on the LSL Wiki: http://www.lslwiki.net/lslwiki/wakka.php?wakka=multithreading, which is entitled "multithreading" and discusses this technique. In particular, it says:

"Warning: The practice of multithreading to eliminate script delays is a mildly dangerous one at best, and holds the potential to bring a server to its knees, or outright crash it at its worst. Please, for the love of the hippos, try to refrain from multithreading unless it is absolutely necessary for a script to have no script delay. A multithreaded script can cause problems for dozens or even hundreds of users if done needlessly. Multithreading can cause unnecessary strain on sims or other servers, and should be avoided when possible."

Now, it seems to me that they're talking only about multithreading to avoid script delays (not the case here), but then takes the reasons against doing that and applies them to multithreading in general - the last two sentences in particular, taken in isolation, would seem to apply to my situation as well as to someone bombarding the system with emails or suchlike.

Am I right in assuming that the kind of thing I'm planning on doing is not going to cause server overload, or are they literally true when they say "multithreading ... should be avoided when possible"?

it would really depend on what you are trying to do. I think they were a bit overly dramatic in that entry, but there are things that could be bad to do, like trying to override the delay on rezzing objects, or something of that nature.

Having said that, I use multithreading in many of my products. My collar, for instance, uses 22 multithreaded scripts, and yet, is lower on sim resources than my competitor, who uses 8-10. When used responsibly, and to simply do several different tasks at the same time, it's not only fine, but decidedly a better solution. So don't be afraid to try, at worst, the sim *could* die, but no *body* dies.

Multiple scripts also makes it far easier to modularize your code.

This makes it easier to test and upgrade.

Indeed, that's a worthwhile goal in itself, for all sorts of reasons including yours.

Thanks for the reassurance, everyone - off now to go and split some scripts!

The main reasons I use multiple scripts is as Krista has already poined out, modularisation, and code reuse.

The majority of projects almost certainly end up having commonalities and eventually you get to the point where you can factor out the basic functions to a set of reuseable scripts.

I have a set of standard scripts that I reuse in most of my projects. Between them they handle system configuration, updates, UI/Dialog /Message handling, inworld 'database' lookup, email, etc etc.

I can swap them in and out as required and know they all work without having to reinvent the wheel each time.

As for the effects on the SIM, well yes multiple scripts will add a heavier load but as Darien quite rightly points out, one script can be worse than several depending upon exactly how they are set up to work.