You admit casually yourself it has a slow script engine, does this not set more of an example for necessity?
No. The point is that only cpu intensive programming truly benefits from multithreading. Because mIRC is slow, people don't use mIRC for cpu intensive programming, so no one will gain from a change like this.
Also, multithreading a slow engine will give you the same slow engine. The best solution is to make the engine itself faster-- using multithreading in hopes of getting better execution speed is just a workaround.
Depending on what you program it may vary but most everything
has to deal with the CPU eventually and all the processes
running on the machine stand in line waiting for an open queue.
when you add another thread of the process, its like freeing up
another hand for it to do its work. While one hand reads a file
the other hand could be doing a search for a file, and the more
threads you add, the more hands can be filled with worthwhile
tasks. but its important to understand theres more than one way
to multi-thread, you can duplicate the whole process, or you could duplicate a few snippets of functions. There is nothing
new that cant be grasped by the new user that he hasnt already
learned from mIRC at this point. A user doesnt have to
synchronize if he doesnt want to, and he doesnt have to use
threads either, they should be as optional as having a loop or
event in the script.
So there is more to be gained here than just speed alone, but
a new tool for efficiency and the understanding of how this
powerful tool could be useful.
homegrown solutions on the scripting environment is only a temporary compromise to accepting a better solution
Wrong. It's not a temporary solution. It's a fully workable and usable solution in this context. Certain programming paradigms do things in a certain way; usually there is no ONE best solution, there are many. mIRC has one of many best solutions. Take, for example, the way that an imperative language like C implements an event-driven model like the windows api-- someone can say "you should use an event based language to solve this problem!", but frankly, the solution given in C is perfectly capable on its own. Should we rewrite windows into an event based language just because the windows api is event based? Frankly, asking for multithreading in mIRC shows a lack of understanding of mIRC's programming paradigms.
lol well from the sound of it, I think you just think I have a
scripting problem, and so instead of arriving at a 'homegrown'
solution like you suggested that I have concocted a catch-all solution.
But regardless of what you might think, the problems I have
cannot be solved by fancy scripting, thus returning me to a DLL
which is a convenience to have the option, but seeing as I do not
know C++ very well its not so feesible. so I continue to make
the stand (That argv0 will not let stand! :P) for multi-threading
to be an acknowledged suggestion.
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.
Multithreading would not make any of those any more feasible in mIRC because mIRC's script engine is way too slow to support any heavy search loops or video/sound processing to begin with. Again, the solution would have to be to improve mIRC's script engine itself, not duplicate it twice and have it run in a thread. But if you really want you can already use dlls to do heavy processing, and then you have full threading capabilities to your hearts content. By the way, most people would go down to C for video processing anyway, so this is not such an outlandish idea.
It doesnt matter if it was improved or not, it could still
utilize the extra thread, and you dont have to encompass the
entire scripting environment if its not necessary or compromises
safety.
You also didn't answer my "Are there any problems that I cannot solve given mIRC's single threaded environment?" question, you just said you think there are some-- I'd love to hear what they are. Yes, you can leave out dlls.
So you basically want to know what I'm working on that can't
keep up with mIRC, lol and then once I tell you, you will
probably suggest it be done in a C++ DLL or some other enviro
and that mIRC really isnt made for that.
Right now i've been working with genetic algorithms to find
optimal patterns, and even with the bare minimum of looping it
still does not loop/draw as fast as I know whats capable.
I'd take it to another language but its the quick creation
and low maintenance of edit/picture windows that attracts me to it in the first place.
every individual cell/pixel moved could count as an individual
with its own internal states, so this is where threading could
be utilized.
Then, in another situation I have hash records that is storing
data and I plan to do recursive searches over it, another
element that could expand faster search times, how much faster?
who cares, faster is always better than, less faster?
But frankly, all of what you're saying is hypothetical. mIRC *could* be faster. Obviously it would. How much faster, however, remains to be seen. From experience, multithreading really is not meant to give speed increases, so you shouldn't expect to see much in speed, only bandwidth. If mIRC is a 56k modem, then a multithreaded mIRC would just be 2 56k modems. You may be able to download 2 files at once now, but you're still only getting them at 5kb/s, so what's the point? You also have to realize that this is a cost benefit scenario, the cost of having K waste his time on multithreading is not worth the few benefits you get from a *potentially* faster mIRC.
To myself, this seems like the best utilization of time,
unless you've got a better one.
As an aside, I don't know of any applications that converted from single to multithreaded with a considerable enough speed boost to conclude that mIRC should go down the same path. To really sell this idea to anyone, you'd really need to show success stories from other applications or at least show HARD evidence that mIRC could gain from an X% speed boost, or be able to solve a specific problem that is currently unsolveable (period, not unsolveable in an easy way. you can omit dlls from the picture though, to be fair). Currently though, you seem to just be saying "multithreaded would be cool cause it's a buzzword and why not?!" -- no real uses, no real proof of speed gain, nothing.. so where's the incentive?
I think I've already made it clear what I think the
incentives are, that it would encourage a new crowd of people
to make new applicable bigger and better projects.
Its also not a buzz word, I was just reading up about it recently
and it seemed like a good idea and it applied to my situation
of what I thought I wanted in mIRC, thus it became...
a suggestion, properly placed in "Feature Suggestions" on
a mIRC forum, and thank God not in the "Private Messages" of
yours truly argv0 the #1 negative nancy. Can i have an amen?