As an aside to everybody wanting multithreading so badly-- there is no advantage to multithreading in mIRC, simply put.
+1 Disadvantage
multithreading is only used in situations where you really need to pull as much horsepower from the cpu as possible, or conserve memory instead of spawning processes in the case of server daemons.
A good description of what multithreading is designed for.
Since mIRC is not a server daemon and only resides in one process, clearly the use would be to take advantage of multi-core cpu's.
I'm not sure what you mean by that, are you saying that the
multithreading is pointless? or that we should wait on faster
Cpu's? because, when you create a multi-thread process it sets
aside more computational resources for utilization, and when I
think of mIRC, I think of it as a full featured swiss army knife.
And it seemed to me that its all about trying to make a better
experience for the user, so to release some computational
imagination to the end-user in a safe way I think would be an
addition to the mIRC package.
Unfortunately, mIRC has a dead slow script engine to begin with and no one is really using it for heavy processing, so threading is not really necessary.
You admit casually yourself it has a slow script engine, does
this not set more of an example for necessity? And I think in
this case, effect exxagerates the cause, the reason why no one
is using it for heavy processing is because its not as much an
option, metaphorically pushing the end-user out the window to
try to learn something else.
Yes there are times when threads are necessary that dont fit into the two categories above-- however mIRC has its own homegrown solutions to those problems, and they're not so terrible either.
homegrown solutions on the scripting environment is only a
temporary compromise to accepting a better solution, it is
not an answer to a call that must befall it eventually.
It comes down to this: you have to ask yourself-- why exactly do I need multithreading? Are there any problems that I cannot solve given mIRC's single threaded environment?
Then I ask you this-- Who doesn't need multi-threading?
Everyone in some fashion could use this, from simple things like
loading files and redundant searching in loops, video and sound addons.
"Are there any problems that I cannot solve given mIRC's single threaded environment?"
speaking for myself, I believe this to be correct, unless you
also encompass a C++ DLL on your single-thread environment, then
thats a different ball game.
also it occurs to me that programming for a multi-threaded
environment shouldnt be entirely difficult a process, as it
would be a layer that would have to be distributed to where
needed, and is only needed in the scripting environment, so
why not just allow the script parsing interpreter duplicate
itself so it could run as many instances of scripts in an
optionally parallel fashion, i dont think thats a huge rewrite
like everyone thinks.
Most programmers and application designers steer clear from multithreading for as long as humanly possible, because it's really not worth the hassle 80% of the time. This case easily falls into that 80%.
I think you underestimate the results that could be obtained,
to get a gauge of what people think is possible and have
accomplished, just look at all the productions on the script
sites. I'm lucky if I find 5 addons or script that impresses me,
because the rest are always MP3 players, nickname identifiers,
and tag makers. So either people don't have alot of imagination
or thats all that people are left to believe they can create
with mIRC, and that really saddens me with that impression, lol
when I say I script in mIRC i want to be proud of it, not ashamed
that its not a full featured language. lol
so hearing all above, i'm still suggesting multithreading to be
a credible and viable solution to what was stated before,
"mIRC has a dead slow script engine to begin with"
