mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Sep 2003
Posts: 4,230
D
DaveC Offline OP
Hoopy frood
OP Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
A command to yeild processor control.

Im not really sure if it would be possable, but the ability to let other script events / actions mirc needs to take (ie keeping send,recieves,channels uptodate), while still returning control to your script after these have occured, would be a nice addition.

Im not looking to create a MCP overlording whats going on in mirc, but rather I thought of this becuase I have a script that lags the heck out of mirc as it loads up and also as it does a particular function.

This is just a post to discuss/suggest the idea of a /YEILD command.

I could have done a rewrite on my script when it became clear how time consuming it was, and I would have if it was any worse than it is.

Joined: Sep 2003
Posts: 9
S
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
S
Joined: Sep 2003
Posts: 9
so you could put a /yield inside a long loop and let mirc do its business without the loop freezing it until its done? i like this idea. unfortunately then you have problems with consistency, because how do you handle events that get triggered while your loop is still running? queue them? but you still have the problem of the state of logs/windows/buffers changing mid-event. i just dont think this is feasible, because it would require maintaining an entire seperate 'clean' environment for the yielding script to run in, and then somehow reintegrating that environment with the real one when it was done. the only way this might work is to cripple /yield into almost uselessness by not letting mirc do anything that could affect a script during a /yield.

Joined: Sep 2003
Posts: 4,230
D
DaveC Offline OP
Hoopy frood
OP Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
omg after reading what i wrote again today i realised how hard it would be to implement, maybe not becuase exactly for your reasons although there also very valid. Rather my original concept of it was that it wouldnt be much harder, than if the script in question was simply calling each of the routines needing servicing, like they were subroutines, apon there completion, just moving on with its code. It dawned on me how spaggettied you would end up, if say one of those routines being called also did a /yeild, maybe you would find your way back throught levels of yield calls maybe you would just go on untill you recive a nice STACK OVER FLOW message, something to make your day feel real good them!


Link Copied to Clipboard