This shows you the differences between two versions of the page.
|
critical_events [2011/10/17 23:51] 127.0.0.1 external edit |
critical_events [2018/08/17 12:36] (current) saturn Document new insights gained over the course of twelve years (first cut) |
||
|---|---|---|---|
| Line 32: | Line 32: | ||
| [message loop] -> [non-critical event] -> [message loop] -> [non-critical event] -> [message loop] -> (etc) | [message loop] -> [non-critical event] -> [message loop] -> [non-critical event] -> [message loop] -> (etc) | ||
| - | And these execution stacks are not allowed: | + | In contrast, this execution stack must never occur: |
| [message loop] -> [critical event] -> [message loop] -> [critical event] | [message loop] -> [critical event] -> [message loop] -> [critical event] | ||
| + | |||
| + | Fortunately, mIRC is smart enough not to allow nesting of two critical events like that. To that end, mIRC postpones processing other critical events until the current critical event is complete. As a result, mIRC will never process incoming events from sockets to IRC servers in a nested fashion, and so the JOIN-after-QUIT case sketched above can never occur in practice. | ||
| + | |||
| + | That leaves this third category, for which it is less clear whether it should be allowed or not: | ||
| + | |||
| [message loop] -> [critical event] -> [message loop] -> [non-critical event] | [message loop] -> [critical event] -> [message loop] -> [non-critical event] | ||
| - | One may get away with the latter of those two, but the former really poses a problem, and this distinction really can't be made beforehand - hence the error when trying to use $input, etc. from critical events. | + | That case would be technically possible. However, deferring the processing of incoming socket messages is never a good idea anyway. For example, if $input is used from an "on TEXT" event, and the user does not actually provide any input, then mIRC will not respond to any incoming "PING" requests from IRC servers for that duration either. The end result is that the IRC connection will time out. It is for that reason that mIRC forbids the use of script-blocking identifiers such as $input and $dialog from critical events. |
| - | Unlike $input, both the WhileFix DLL and COM-based script delaying snippets do not make the distinction between critical and non-critical events, so you can use them from critical events as well, resulting in the disallowed cases above. mIRC isn't really prepared to handle this, resulting in potentially undefined behaviour; in practice, mIRC does its best to save itself by delaying the execution of critical events until the original critical event is done executing - so in the case of a COM-based script delaying snippet for example, no critical events will be processed until the snippet times out and returns. | + | Unlike $input, both the WhileFix DLL and COM-based script delaying snippets do not make the distinction between critical and non-critical events, so you can use them from critical events as well. Again, in that case no critical events will be processed from the nested message loop - so in the case of a COM-based script delaying snippet for example, no critical events will be processed until the snippet times out and returns. However, non-critical events may indeed be processed (the third category above). At that point it is entirely up to the scripter to prevent that the scripted delays cause problems for the IRC connections. |
| Again, all of this happens from a single thread: mIRC's main thread. If mIRC were multithreaded, everything would be different. Hence, these are issues related to mIRC's internal design, which is not documented anywhere. Snippets like the one here really push the limits with respect to what can be done without breaking the internal execution model. | Again, all of this happens from a single thread: mIRC's main thread. If mIRC were multithreaded, everything would be different. Hence, these are issues related to mIRC's internal design, which is not documented anywhere. Snippets like the one here really push the limits with respect to what can be done without breaking the internal execution model. | ||