This is going to be a long post. I thought I might stick up for khaled here, for a change. That's alot of work and it might actually wreck existing scripts, because if the events are set up to run on different threads then race conditions can be introduced. Yes, it would be cool to be able to do that, but it's not for everyone. If you're not careful some pretty scary bugs can pop up. I like the loop detection idea, but that would still be alot of work. In this case, mIRC appears to be entirely single-threaded, relying on non-blocking/asynchronous sockets. GUI stuff isn't much of a worry, because it rarely uses much CPU at all. That means when it runs into a blocking operation (e.g. a loop) that won't allow the GUI to update for a long time, things lock up like that). To make the change to run the script processing (all except user input), GUI processing and socket processing, on individual threads, can be a scary task for an application that is already quite well established. That's where mIRC would need to go, else risk possible race conditions. Maybe a better idea for things that could potentially lock up your mIRC looks like this:
Code:
alias qwerty {
  set -u5 %x 1
  asdf
}

alias asdf {
  ; loop condition
  if (%x != 1) {
    return
  }

  ; loop body
  noop

  ; loop jump/reset
  .timer -m 1 1 asdf
}


You could modify it, turn it into a post-test loop or add/remove a condition quite easily. You could speed it up by adding a loop that iterates 10 or 20 times at once before the function returns and allows socket/gui processing. Or you could just save files often, and be ready to press CTRL+BREAK, which is probably a good idea anyway.