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.
