What you guys are refering to is "race conditions", and they're a very common issue in any multi-threaded environment. The thing is, once you get the nack of it, avoiding race conditions is easy.. even second nature.
Yes, if you have two threads working on the same varaible, there's no telling which thread will get first dibs, so it's much like working with UDP datagrams (coming in at an almost random order). However in many situations the speed advantage is more important and little harm can become of a race condition (like in drawing on a picture window).
You only get into problems in environments where an event occures in one thread (like an on-join) and an action is taken in another (like oping the user). This leads to a common race condition where the variable that contains the user's nick changes because someone else joins the channel just after them. When the second thread finally gets around to oping the user, its the second user who gets opped instead.
However, even a novice user could see and avoid that, so the flexibility of multi-threading (if ever implimented) shouldn't be restricted due to simple mistakes people COULD make.
I would also like to suggest the command "/doevents" similar to Visual Basic's "DO EVENTS" command. It basically ends the alias's turn, allowing other waiting events to process. This alone should be a solution to most multi-threading woes (with exception to $findfile and /filter)... when used, a new thread is temporarily opened to process one waiting event, and then it continues processing the alias where it left off. This would obviously be handy in especially consuming WHILE loops.
- Raccoon
