Forums Feature Suggestions Multi-Core Support

Currently, mIRC itself can at times lockup from anywhere from a few seconds to a minute or longer, depending on anything from a netsplit on a large network, viewing a large channel log with the built in log viewer, or CPU hungry script(s), for example, a seen script working during a netsplit, or a Hash Table Viewer/Editor, trying to view 15,000 items, in alphabetical order.

This of course can cause mIRC to disconnect from network(s) with a "10053 Software Caused an Abort" error on our end, with a "Ping timeout" or "Connection reset by peer" (what other people would see on the network(s) in the channel(s)), as mIRC seems to be unable to process the ping/pong in order to keep the program connected to the network(s), while processing anything that is CPU intensive.

I am suggesting possibly putting scripts and the internal log viewer into separate threads or cores, to prevent these possible scenarios that I have encountered on occasion.

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.

Not sure if you know what this suggestion imply but note that a multithreaded application is much harder to code, to maintain and to debug, I really doubt it's on Khaled's todo list.
Now if you want to see the scripting engine 'threaded', how would you see it ?

Just to clarify: if the scripting engine was on a separate thread from the UI/socket layer, your life as a scripter would be about 100x more difficult. Such a change could not be entirely encapsulated within mIRC's internal code, it would require changes to scripts to lock and synchronize the UI/socket/script layers. Many commands and events rely on the fact that mIRC responds to the server, or otherwise performs an action, immediately before sending/receiving any more data to the underlying socket, since it is all single threaded. Scripting a simple ON TEXT theming script would now create a race condition whereby the unscripted join event could fire *after* an on text event from a user, causing you to see things like the following, if you were not careful in synchronizing the threads:



mIRC could not do this synchronization automatically, otherwise it would collapse the overall behaviour back into a "single threaded" one, effectively defeating the purpose of separating the script and UI/socket threads. If you're asking for mIRC to relieve its responsibility of synchronizing the script/UI/socket layers, you're really asking to take on that responsibility yourself. Someone has to do it.

Using the whilefix DLL can generally get around a number of things that cause Mirc to freeze. While this is a somewhat hacky way to get around it, it IS a quick fix.

Well no, not really. The only thing whilefix does is process window messages to let the window update. The major chunk of mIRC (its script processing "brain", and sockets by extension) are still frozen and unusable, so whilefix is quite literally superficial. That might work to improve responsiveness, but there are other equally effective ways to do just that without a dll-- like splitting up your loop into ~5000 count iterations and separating them by a "0 second" timer. In fact, it's likely that this would be *more* efficient than whilefix, even with the overhead of /timer's command parsing and a new script call. And the latter method lets *all* of mIRC update.