-3

I am pretty sure Applicataion.DoEvents() in Windows Forms. is a very early, very primitive, WindowsForms only form of Multitasking. It has all the telltales and mechanics:

  • Pausing execution of the calling Event.
  • Making the rest of said Event a continuation to be run later.
  • Allowing the other Events/Processes to run. Just with some extra issues, because the MT is implemented via the EventQueue. Possibly even a recursive call to the Queue.

But I just ran into a person that insists it has "nothing to do with Multitasking", which I cannot reconcile with my understanding of the Function or the of Multitasking.

Note: I explicitly consider Mutltithreading only an implementation for Multitasking. It is clear that DoEvents() is not a form of Multithreading, as we all know how poorly that one works in GUI Environments.

TylerH
  • 20,799
  • 66
  • 75
  • 101
Christopher
  • 9,634
  • 2
  • 17
  • 31
  • [Application.DoEvents()](https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Application.cs,1022) runs the message loop (see the note there). Like `ShowDialog()` does. Follow the internal [RunMessageLoopInner](https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Application.cs,3355) (and the notes left there). Plus, of course, [Use of Application.DoEvents()](https://stackoverflow.com/a/5183623/7444103) – Jimi Oct 20 '19 at 12:51
  • @Jimi: Yes, that is *how* it implements multitasking. Doesn't really answer my question. – Christopher Oct 23 '19 at 22:47
  • 1
    Yes, it does. Since it's just a matter of language. Do you want to call it MultiTasking? Or Task Switching? You do, in a way, return control to the System. In a way. But this is not how the System implements MultiTasking (we don't even begin to talk about MultiThreading). So, it's simply a choice. Do you want to call it that, to explain, in way, what is happening when you run the message loop? It might be ok, but you have to know what it's really happening out there. That's the only thing that matters (IMO). – Jimi Oct 23 '19 at 22:53

2 Answers2

4

I am pretty sure it is a very early, very primitive, Windows Forms only form of Multitasking

You are pretty close to correct on all counts except for your conjecture that it is for WinForms only. "DoEvents" precedes WinForms; it was present in Visual Basic long before WinForms was invented, and "pump the message queue" obviously precedes VB also. And it was a bad idea and easily abused then too.

Making the rest of said Event a continuation to be run later.

DoEvents doesn't really make anything into a continuation the way that say, await does. Whatever event is currently "in flight" when DoEvents is called has its state on the stack, and the stack is the implementation of continuation in this case. This is another point against DoEvents -- unlike await, it eats stack, and therefore can contribute to an overflow.

I just ran into a poster that insists it has "nothing to do with Multitasking".

You should ask the author for clarification then, since that certainly sounds wrong.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 1
    @Christopher: Instead of getting into the weeds of what makes something "real" vs "pseudo", or implementation details, instead consider what effect a technique is intended to achieve. If the effect is intended to achieve orchestration of multiple independent or dependent tasks, does it really matter whether it is "real" or "pseudo" multi-tasking according to someone's opinion of what makes a thing "real"? It does not. Instead, concentrate on learning what the pros and cons of the technique are, and what the current state of the art is. – Eric Lippert Oct 21 '19 at 06:21
  • "Instead of getting into the weeds of what makes something "real" vs "pseudo", or implementation details, instead consider what effect a technique is intended to achieve." That is literally what I am doing. He was the one that kept bringing up "real multtiasking", as if that meant anything. – Christopher Oct 21 '19 at 11:43
1

Well, it's called Preemptive Multitasking, meaning "interrupting a task". You do multiple Tasks, but never two at the same time. It's not about using multiple cores of the CPU, but a way to control multiple activities inside your program. Common Sample is, to give the program a chance to handle mouse movement by the user, while doing a lengthy operation, running something that can be considered a "batch"-job.

Normally you don't have to care about this "DoEvents", but if you know, you have a procedure running for more than 1 second, you should call it manually, you pass the control to another method thereby, you stop your own code, let other code run, and than you continue with your own code. So it's never asynchronous, but still some kind of "multitasking".

It's more a control structure, the important thing is, you do not know what's going on inside, you call it "just for case" - somebody else might need the CPU for a millisecond.

There is no external task scheduler interrupting your code and doing a context switch, you have to "behave" by interrupting your code yourself, if you do something lengthy. It is a convention that you do only "small" things in event handlers and return the control to Windows as soon as possible,either by finishing the method, or by calling DoEvents.

Holger
  • 2,446
  • 1
  • 14
  • 13