Yes, I know there's 2 other discussions on this. One of them missed the point and the other quickly went into a philosophical rant about whether there's an implicit improvement in multithreading (Frankly, RRX's post on the last page was the first to have useful content).

My very simple solution: A new command, (/thread [command]) that causes a command (or alias) to run in a new thread and the original thread continues immediately (or as close to immediately as possible). Such behavior, minus the actual threading, could be simulated with:

alias thread {
  .timer 1 0 $1-

That's it. Variables may or may not match for each thread (whatever's easiest for Khaled). Sharing hash tables and other global resources would be useful, but still not required.

In other words, it'd be like threads in other languages: If you want locking, you can code it yourself. Same thing for semaphores, dispatching, and every other management function. I have no doubt that Khaled COULD add easy pre-built systems for such features, but I see little need.

Simple sleeping can be done with just waiting for a variable to change, and another thread changes that variable. If variables aren't shared, a file could be used in place of a variable.

Threads don't inherently need complex management. MIRC's language is powerful enough that if a given application needs such management, a competent scripter could add it without much trouble.

Now, most of my experience with parallel processing comes from Java, but I see no reason why this simple solution wouldn't work.