-2

I would like to know how C# manage and fire events behind the scenes.

For example, in windows forms applications, If we create a button, does C# use polling mechanism to detect button click events?

If so, What is the frequency of this polling? Does it run in separate thread?

Is there a maximum number of events to respect in order to preserve responsiveness of a program?

Update

After reading answers and comments, I understand that windows forms use message pumping. So now, I have hard time to understand how message pumping works. According to @xanatos comment "Winforms uses the Windows API method GetMessage. The GetMessage then returns the first message of the message queue or, if there are no messages, puts the thread into wait mode until a message arrives."

I'm newbie to programming and I cannot see how to put the thread into wait mode until a message arrives. This phrase seems to me as a while loop (or polling). What's the mechanism used to put the thread into wait mode until a message arrives?

Mhd
  • 2,778
  • 5
  • 22
  • 59
  • 1
    In Winforms messages are passed and processed using the main event loop. https://en.wikipedia.org/wiki/Event_loop#Windows_applications –  May 02 '17 at 13:35
  • Your question is too broad. If you want to ask how the `event` keyword is implemented then it is one question (probably already answered somewhere), to ask how the Winform events work is another question (Tim gave a correct and complete enough answer). To ask how other subsystem handle events is a third question. – xanatos May 02 '17 at 13:40
  • Possible duplicate of [Difference between event handlers and callbacks](http://stackoverflow.com/questions/2069763/difference-between-event-handlers-and-callbacks) – Matthew Whited May 02 '17 at 14:15
  • Regarding the updated question, that depends on the implementation. Look at the c++ source for winmain if you really want such info. –  May 02 '17 at 18:36

1 Answers1

2

WinForms runs on top of the underlying Windows API. WinForms Events fire in direct response to window message from the operating system-- not polling.

A simplified explanation is that each "window" in the operating system has an associated message queue. The operating system sends messages to this queue in response to user inputs, screen resizes, etc.

WinForms has, in the "main GUI thread" of your application, a message pump that listens for these incoming messages. As they are received, it creates and fires events that your application can catch and respond to, without having to deal with the underlying mechanics of a message pump.

The message pump is an efficient loop that causes the thread to sleep until a message is ready, then wake up and process the message.

Tim
  • 5,940
  • 1
  • 12
  • 18
  • "The message pump is an efficient loop that causes the thread to sleep until a message is ready" that's the mechanism that I want to understand. How does message pump work without polling? – Mhd May 02 '17 at 13:46
  • @Mhd Simply put, the Winforms uses the Windows API method [`GetMessage`](https://msdn.microsoft.com/en-us/library/windows/desktop/ms644936(v=vs.85).aspx). The `GetMessage` then returns the first message of the message queue or, if there are no messages, puts the thread into wait mode until a message arrives. – xanatos May 02 '17 at 13:51
  • @xanatos I'm newbie to programming and I cannot see how to put the thread into wait mode until a message arrives. This phrase seems to me as a while loop (or polling). What's the mechanism used to put the thread into wait mode until a message arrives? – Mhd May 02 '17 at 14:12
  • @Mhd You call the `GetMessage` method, the `GetMessage` method does everything. It returns a message or suspends the thread until there is a message and then returns the message. From the POV of the caller of `GetMessage` there is no difference. One call to `GetMessage` == one message – xanatos May 02 '17 at 14:14
  • Events are based on the idea of interrupts. The thread does not need to wait for a message. Instead when a message is received the callback procedure that is registered to listen for that event is called. The message pump in Windows create software interrupts as not all events are based on hardware interrupts. https://en.wikipedia.org/wiki/Interrupt – Matthew Whited May 02 '17 at 14:19
  • @MatthewWhited Windows events aren't based on that from what I know... Each thread has a "running/paused" bit. The windows scheduler runs for a timeslice every "running" thread. When a message is put in a queue associated to a thread that is "paused by `GetMessage`" then the thread is put again in the "running" state and then before or later the Windows scheduler will run it again (and the `GetMessage` will see the message and "return") – xanatos May 02 '17 at 14:23
  • Windows events are software interrupts as I noted. – Matthew Whited May 02 '17 at 14:31