|
Joined: Jan 2003
Posts: 3,012
Hoopy frood
|
OP
Hoopy frood
Joined: Jan 2003
Posts: 3,012 |
Tell me if this would be too hard to impliment Khaled, but here's the plan...
Have an identifier, much like timer (kinda) that bascially would start a new thread and call the alias under that thread? Something like
/thread /somealias alias somealias { /echo -s This is a different thread var %a = 0 while (%a < 1000) { /inc %a } /echo -s This won't halt mirc from processing var %a = 0 while (%a < 1000) { /inc %a } /echo -s No matter what goes on inside of it. }
I was thinking about my programs I've been playing with in C#, and the reference to a class method called by a thread occured to me. Im not sure on how easy/hard this would be to impliment, as I don't know how mIRC is setup. I do however think it would be a nice addition, and very useful. Especially for things like loading large lists into listboxes with loadbuf, or even $findfile, $finddir. Additionally, you could do multiple computations at once.
Again, I'd be interested on input.
(BTW, pardon grammer, its 3am here--fingers are fatigued >:P)
-KingTomato
|
|
|
|
Joined: Feb 2003
Posts: 309
Fjord artisan
|
Fjord artisan
Joined: Feb 2003
Posts: 309 |
I reckon it would be hard to do; and imagine just how buggy mirc would get - what with tracking down such nightmares as locking errors (three threads running, the higher one takes control then the middle one is handed back control by accident and it changes data; screwing up the lowest one)...
I would rather not see mirc go less stable; if at all possible
|
|
|
|
Joined: Jan 2003
Posts: 3,012
Hoopy frood
|
OP
Hoopy frood
Joined: Jan 2003
Posts: 3,012 |
I don't see any problem with "one handing back control, screwing up data". I've been using threads for a short while, but all the time I have is one messes up, it never effects the 'parent' thread. All it does it kills itself. Anyways, what you you screw up that you can't alreayd do currently? The only difference would be mirc would continue to run, instead of stall and kill connections to servers. Say if your called threwad went into an infinite loop. mIRC would continue to run fun, and the thread itself would be th eonly thing to 'die'.
-KingTomato
|
|
|
|
Joined: Jun 2003
Posts: 195
Vogon poet
|
Vogon poet
Joined: Jun 2003
Posts: 195 |
actualy there could be problems with shared resources. This is what the critical section object was made for. Openeing a thread for just any plain alias would be nice but i would suggest limiting it. For example only one thread can write to a file or draw to a picwin at a time.
Another solution would be add switches etc.. for the commands and identifiers (like findfile and while) wich can halt mirc. such a switch will cause it to run in a new thread but not just any ole alias could.
Have Fun
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
What you guys are refering to is "race conditions", and they're a very common issue in any multi-threaded environment. The thing is, once you get the nack of it, avoiding race conditions is easy.. even second nature.
Yes, if you have two threads working on the same varaible, there's no telling which thread will get first dibs, so it's much like working with UDP datagrams (coming in at an almost random order). However in many situations the speed advantage is more important and little harm can become of a race condition (like in drawing on a picture window).
You only get into problems in environments where an event occures in one thread (like an on-join) and an action is taken in another (like oping the user). This leads to a common race condition where the variable that contains the user's nick changes because someone else joins the channel just after them. When the second thread finally gets around to oping the user, its the second user who gets opped instead.
However, even a novice user could see and avoid that, so the flexibility of multi-threading (if ever implimented) shouldn't be restricted due to simple mistakes people COULD make.
I would also like to suggest the command "/doevents" similar to Visual Basic's "DO EVENTS" command. It basically ends the alias's turn, allowing other waiting events to process. This alone should be a solution to most multi-threading woes (with exception to $findfile and /filter)... when used, a new thread is temporarily opened to process one waiting event, and then it continues processing the alias where it left off. This would obviously be handy in especially consuming WHILE loops.
- Raccoon
Well. At least I won lunch. Good philosophy, see good in bad, I like!
|
|
|
|
Joined: Dec 2002
Posts: 39
Ameglian cow
|
Ameglian cow
Joined: Dec 2002
Posts: 39 |
Avoiding thread deadlocks and starvation is dead easy? You should tell my professor that since he clearly was of a different opinion! Once you go beyond doing very simple stuff threads are extremely susceptible to complete screwups even by seasoned professionals. Depending on what you are trying to do, thread communications and collaboration is very hard indeed. The current collaborative event model for concurrency is actually quite sleek and resembles a kind of setup used by some application servers. I really don't feel threads belong in mIRC.
|
|
|
|
Joined: Jun 2003
Posts: 195
Vogon poet
|
Vogon poet
Joined: Jun 2003
Posts: 195 |
racoon said Yes, if you have two threads working on the same varaible, there's no telling which thread will get first dibs,
actually you can tell because you can design threads to wait while another thread is accesing a variable. it requires more thought on mIRC's part tho.
Its not a complex situation to gaurd against threaded applications. interprocess syn objects such as semaphores, mutexes,waitable timers, and more make it quite easy.
to vague: your professor isnt entirely incorrect. there are alot of issues that need to be addressed but none of wich make threaded applications all to dificult. It typically requires a knowledge that goes beyond that of the basic C programming course (even most intermediate courses) so typically instructors will err on the side of caution in any matter using more involved concepts such as inline asm (wich i find extremely easy).
I agree i dont see mIRC supporting generalized threading any time soon however we already have dllcall. It would be quite easy for mIRC to add support for some of the more time/resource consuming commands/ident. for example a $findfileex ident wich calls an alias (from a new thread) for each file it matches. this avoids lock up and achieves the same results.
On a bit of a side note there is another idea. The reason mIRC locks up is because its main message loop doesnt call GetMessage for a predefined period of time. Windows flags the applications as hung (See the IsHungApp API in the MSDN). For code (such as $findfile) that is known to take a long time you can simply add a GetMessage and DispatchMessage call inside the loop. This keeps the app from hanging. You would filter out all messages except for WM_TIMER so that no events or other code is triggered during the loop.
Have Fun
|
|
|
|
Joined: Dec 2002
Posts: 39
Ameglian cow
|
Ameglian cow
Joined: Dec 2002
Posts: 39 |
Rest assured, my professor is not wrong. I also quite share his opinion personally. Concurrent programming using current models such as semaphores, monitors, and higher level concepts such as Linda tuple spaces really is hard for anything but the simpler cases. While many of the usual uses of concurrent programming, such as GUI workers thread separation, are well explored and not that difficult, anything more complex soon gets very hairy, especially when greater multi processor utilization is the goal. There is a lot of research going on to provide better concurrency support in new programming languages. Efforts such as Oz and Erlang mark progress in that direction.
|
|
|
|
Joined: Jun 2003
Posts: 195
Vogon poet
|
Vogon poet
Joined: Jun 2003
Posts: 195 |
I disagree. Im currently working on a dvd authoring/recording application. The built in encoder has mutli processor support (im currently running dual amd 2800's). I cant imagine what you consider to be too complex because As far as mProcessor and mThreads none of it is even a challenge. The hardest part i find is writing out the DVD header format and recognizing the various tags (for multiple format support) as well as supporting several of the major recorders.
Syncronization and communication between multiple processes/threads is not a difficult chore its just a chore. It either works and your good or it doesnt and you hammer away at it until it does.
I think one such problem is the programmer themself. They start toying with the idea using a simple worker thread to handle some lengthy calculation (CRC on a 500 meg file for exmaple). Later on when they actually try to tie the two togethor making one thread pause while another is using a shared resource and so on it starts to get a bit more complicated. I find alot of programmers will mess with something for a short time and then move on.
Any thing you can code you can do so in a complex impossible to do way. The real problem isnt in threading its in the programmer using it.
I didnt say your professor wasnt correct only that he was partially so. There are several free applications out using threading and they do so greatly. Most of these apps are written by children (im 15 and i hang out with other younger programmers).
Have Fun
|
|
|
|
Joined: Dec 2002
Posts: 39
Ameglian cow
|
Ameglian cow
Joined: Dec 2002
Posts: 39 |
Believe me, I mean no disrespect, but I really mean that my professor who taught the concurrent programming class I took knows more about these issues than you do. While many applications use threading and do fine with it you are still only describing very simple applications from a resource management point of view. Whenever we are talking about more complex resource management issues, or just a little bit more complicated situations such as the famous problem presented at http://java.sun.com/applets/archive/beta/DiningPhilosophers/ things quickly get harier. And complicated threaded applications really is one of those areas were just slugging it out isn't good enough, it takes planning, experience, and skill.
|
|
|
|
Joined: Jun 2003
Posts: 195
Vogon poet
|
Vogon poet
Joined: Jun 2003
Posts: 195 |
no disrespect was takin. however i dont think spanning several processors is a simple worker thread situation. all programming is a "slug it out" type when you get into more complex systems. noone ever just spews out several hundred lines of code and it works right first time unless theyve done it numerous times.
I dont mean to say that im only referring to resource management. a resource isnt just some data pluged into a projects rc file such as a bitmap or icon. The screen, a particular window,a particular segment in a file (such as the bss or code segment) usb poll lines, port scan lines,and literaly hundreds of other items on a pc are all shared resources.
I think we both agree that complex threading isnt something a first year student would jump right into. Inded it takes skill and experience as does almost any programming youll ever do in any language. some of the issues touched upon here wouldnt really be nessecary to add simple threads to a few commands in mIRC.
I would hope your professor has more experience than I do otherwise you wasted your money ive only been programming for just over 3 years (with a real language that is). Ive never doubted his worth or intelligence only that i have yet to find anything of the level of difficulty were discussing. I would imagine if you were writing an OS things would be different. I Wrote a windows clone for my TI92+ included preemptive multitasking. Altho its a smaller scaled version than her big sister i have nearly 45% of the win32 API written for it I do well understand (from an asm POV) multitasking.
Weve gone a bit off topic (interestingly so however) so to just restate what i said before i dont see adding a few more threaded commands to mIRC that great a challenge (we already have one).
Have Fun
|
|
|
|
|