events blocking or non-blocking?

  • Thread starter Thread starter Robert Conde
  • Start date Start date
R

Robert Conde

Are events in winforms blocking or non-blocking? In other words, when an
event is raised - is it added to a queue or are you blocked until it
finishes executing?

Rob Conde
a.i. solutions
 
Hi Robert,

Events are simple method calls. Only one event is runnign in a thread (that
is common sense). Hoewever event handers can be executed in different
threads and they can run simultaneously.
 
Are events in winforms blocking or non-blocking? In other words, when an
event is raised - is it added to a queue or are you blocked until it
finishes executing?
Click to expand...

in general, winform events are queued. but usually applications are single
threaded and all events are synchronously handled in the same thread. it
means that when an event E is executing, other events are queued but they
are handled after E finishes.

regards,
Wiktor Zychla
 
* "Robert Conde said:
Are events in winforms blocking or non-blocking? In other words, when an
event is raised - is it added to a queue or are you blocked until it
finishes executing?
Click to expand...

The event handler is invoked and execution continues when it returns.
 
Hi Viktor,

What do you mean event's are queued?
There is no such a thing in .NET. Eevent's handers are kept as a list of
delegates, which are abstraction of a function pinters (.NET doesn't have
pointers ofcourse).

Raising an event is simply walking over the list and call pointed methods.
There is no queuing. Other question is that some Windows Forms' events are
raised in response to window's messages, which might be queued.
Control class has BeginInvoke (not to be confused with delegate BeginInvoke)
method which kind of queues a delegate.
 
There is no queuing. Other question is that some Windows Forms' events are

this is what I meant. winform events are just wrapped win32 events. and
win32 events are queued.
 
Wiktor Zychla said:
are

this is what I meant. winform events are just wrapped win32 events. and
Click to expand...

No, they aren't. Many events corresponds to a Win32 message (don't call it
an
event since that's incorrect) but that doesn't mean that they all do. And
it
doesn't mean that all Win32 messages has a corresponding event either.
win32 events are queued.
Click to expand...

Win32 doesn't use the term "event". It's called a "message"
(but you're correct in that they are queued)



/claes
 
No, they aren't. Many events corresponds to a Win32 message (don't call it

yes they are. at least most of them. it's not important then if you say
"some winforms events correspond closely to win32 messages" or "some
winforms events are wrapped win32 events" because it's basically equivalent
to someone without a deep understanding of what is really going on there.
without this knowledge it is only a game of words.
(but you're correct in that they are queued)
Click to expand...

that's the point. and that's how I understood the asked question. I am
afraid, though, that the original question was not clear enough. I am
perfecly aware that Win32 events are in fact messages. I only think that the
harder we try to explain that the more confusing it becomes to someone who
does not have enough win32 background.

Wiktor Zychla
 
Hi Wiktor,

The problem is that if you say that most of the windows form's evens are
queued. One could think "If I raise and event in a class thet derives from
Control class it will be queued" or "Hey, if Windows Form's guys can queue
an event I should be able to do that as well"

There is no such a thing as queued event unless one uses PInvoke and windows
messages. Even using control.BeginInvoke is not the same as posting a
message because the event will be the next thing executed while posted
message will wait in the message queue its time to be processed.

And why sould we make such a simple thing as event complex. Events are not
queued.
 
The problem is that if you say that most of the windows form's evens are
queued. One could think "If I raise and event in a class thet derives from
Control class it will be queued" or "Hey, if Windows Form's guys can queue
an event I should be able to do that as well"
Click to expand...

that would be true, in a sense. if you post several messages to a class that
derives from Control, these messages will be queued and the Control will
respond by raising a sequence of events.
There is no such a thing as queued event unless one uses PInvoke and windows
messages. Even using control.BeginInvoke is not the same as posting a
message because the event will be the next thing executed while posted
message will wait in the message queue its time to be processed.
Click to expand...

that's absolutely true and I am not confused. but depending on from which
side you look at it and start to talk about it, it can sound differently.
look at the original question:

"Are events in winforms blocking or non-blocking? In other words, when an
event is raised - is it added to a queue or are you blocked until it
finishes executing?"

there are in fact two issues there.

"Are events in winforms blocking"?

yes, they are. the event handler blocks the execution and nothing else
happens until it finishes.

"when an event is raised - is it added to a queue or are you blocked until
it
finishes executing"

the "OR" here does not make sense. because the truth is: winforms events are
not queued but corresponding win32 messages are. so, there's no queue of
pending events available to winforms developer but when you peek deeply
under the cover, the win32 messages are there, perfectly queued.
And why sould we make such a simple thing as event complex. Events are not
queued.
Click to expand...

If you now say that events are not queued then one could think: "if an
winforms event is handled and other events occur before it finishes then
these other events are gone, since there's no queue to store them". how do
you like it? ;)

Wiktor
 
Event by itself is just a call. So there are blocking and non-blocking
calls. Queued and non-queued. Form events are either direct calls - blocking
until completed, either resulting in PostMessage, which block until message
is posted and then are queued. If event results in SendMessage it is
blocking. Most of form events are secondary - it means, message was already
processed by underlying infrastructure. However, processing is not complete
until all handlers attached are executed. So, if any of handlers is
blocking - whole event processing is blocked.

So, what is the purpose of this discussion?


Stoitcho Goutsev (100) said:
Hi Wiktor,

The problem is that if you say that most of the windows form's evens are
queued. One could think "If I raise and event in a class thet derives from
Control class it will be queued" or "Hey, if Windows Form's guys can queue
an event I should be able to do that as well"

There is no such a thing as queued event unless one uses PInvoke and windows
messages. Even using control.BeginInvoke is not the same as posting a
message because the event will be the next thing executed while posted
message will wait in the message queue its time to be processed.

And why sould we make such a simple thing as event complex. Events are not
queued.
--

Stoitcho Goutsev (100) [C# MVP]


call
it

yes they are. at least most of them. it's not important then if you say
"some winforms events correspond closely to win32 messages" or "some
winforms events are wrapped win32 events" because it's basically equivalent
to someone without a deep understanding of what is really going on there.
without this knowledge it is only a game of words.


that's the point. and that's how I understood the asked question. I am
afraid, though, that the original question was not clear enough. I am
perfecly aware that Win32 events are in fact messages. I only think that the
harder we try to explain that the more confusing it becomes to someone who
does not have enough win32 background.

Wiktor Zychla
Click to expand...
Click to expand...
 
Hi AlexS
AlexS said:
Event by itself is just a call. So there are blocking and non-blocking
calls. Queued and non-queued. Form events are either direct calls - blocking
until completed, either resulting in PostMessage, which block until message
is posted and then are queued. If event results in SendMessage it is
blocking. Most of form events are secondary - it means, message was already
processed by underlying infrastructure. However, processing is not complete
until all handlers attached are executed. So, if any of handlers is
blocking - whole event processing is blocked.

So, what is the purpose of this discussion?
Click to expand...

Some of the events in .NET are raised in a result of receiving windows
messages. That is true. However, from the .NET programmers perspective
events has some meaning from the moment windows messages is pull out of the
queue and event is fired. To that end events cannot be non-blocking, unless
event handler calls Application.DoEvents.
 
Wiktor,
If you now say that events are not queued then one could think: "if an
winforms event is handled and other events occur before it finishes then
these other events are gone, since there's no queue to store them". how do
you like it? ;)
Click to expand...

Events are raised and they serve as notification that somethig has happen.
So if you move the mouse you will get the event. How they are implemented is
not so important. For example WM_PAINT or WM_TIMER event never stays in the
message queue. However they look like posted messages.

An 'event' in terms of .NET event cannot occure before the winform class
finishes the current one (at least not in the same thread). The life time of
events starts at the moment they are raised. Even thow windows may post a
message in the message queue we don't have an event until the message is
pull out and event is raised. Until the processing of this event is not
finished no other event will be raised. If I use Rob's terminology I would
call this a blocking event. Anyways using .NET in its pure form (no PInvoke)
no one can post or send a message so why we should botter of such a thing as
a message queues.
 
Back
Top