Although that *might* work (I'll leave it to those who have programmed for multi-cores who also know the inner workings of mIRC to say for certain), I see a problem with that. First, a seen script really should not freeze mIRC during a netsplit in a large channel if it's scripted well. And you can very quickly and easily use /filter with a large hash table to view it in alphabetical order without freezing mIRC. I have never had mIRC freeze except when a script isn't written well. Of course, that doesn't mean it can't happen. If all cases where it freezes happen because of bad scripting, then there's no real need for multi-core support... just use better scripts. If there are situations where it freezes for some other reason, then it might be better to fix those specific things than to add multi-core support. I haven't used the log viewer because I prefer the one that is in the script I use and even then, I rarely look at logs. If that really does have problems, then it's probably something that should be individually fixed. Remember that it's a new feature, so probably isn't perfect yet.
Also, keep in mind that even when mIRC is frozen, you may not see the CPU on the core being used hitting 100%. I really don't think it's a CPU core issue at all (I could be wrong). Instead, if there are issues unrelated to poorly constructed scripts where mIRC freezes, the next step should be multithreading instead of multi-core support. Multithreading will let processes in mIRC, such as staying connected and typing work even if a script gets hung up, as long as you're not maxing the CPU. And, like I said, I really don't think you're going to be maxing the CPU in these situations.
In the end, I think multithreading support is a better option. It is more likely to resolve these types of problems. It's also probably on Khaled's list of things to do, though probably not near the top of the list. Just a guess.
