How do threads get entered in to?

  • Thread starter Thread starter Coder
  • Start date Start date
C

Coder

So there are various ways to enter a thread. Example:

- Button click
- Event from delegate call back.
- etc...

In fact, I suppose all entry points are from some form of an event.

Questions:

- When I click a button, does it it get blocked till the last button
click is done? If so why?

- What about other events that I could get such as from MSMQ letting me
know a message has arrived? Or what about if I set up a call back
delegate for a web service to call me back on?

- Do these events call into my thread even if my thread is busy? If
not, how can I get them to call into my thread if my thread is busy?

Thanks!
Coder :)
 
Mmmm...Might be a little off or corn-fused.

Your WinForm application has one thread that is running all the time. When
you click on a button an event is raised in that one thread and it executes
your button code.

Below is a very simple example of what is happening in this thread.

while(true)
{
if(PeekMessage() == true)
then ProcessMessage()
}

PeekMessage() checks to see if there is a message waiting to be processed
and if there is then ProcessMessage() actually does the handing of it such
as calling your button code.

Now.. If you have a second,third,... thread that you created inside your
application then that is a different story. There is no "default" way that I
know of (there may be however?) to raise "enter" a thread in the way that an
event does. The thread is either running or it is not... If it is running
then you are probably in a loop (similar to the above one) doing whatever
your thread does.

Also, keep in mind that a thread is never really busy or not busy.. It is
always busy doing something otherwise it would be be in memory. Granted, it
may be performing a Sleep() or something simlar but it is still always
running/active/etc. in memory.

Hope this helps.
 
Assuming we are talking about a WinForms application...

The underlying architecture of a Windows application (which should include a
WinForms application) is that it is "event-driven".

Everything the operating system wants to tell you about comes to you in the
form of a Windows message. This includes mouse movement, clicks, etc. They
arrive at your application in the form of a "windows message".

Your application, under the covers, is executing a loop, retrieving one
message at a time from the "message queue", and "dispatching" the message to
a processing function (a window proc).

Until the processing function returns, the next message cannot be processed.
This is why one button click must be processed before the next one. Windows
does not "jump in" to your application asynchronously to execute your event
handler. It just "seems" like that is what it is doing.

When you have an event that requires a substantial amount of processing, the
whole message loop grinds to a halt and the application becomes
non-responsive. For example, if your application was doing a large sort it
would not respond to button clicks until the sort completes (unless a
separate *thread* is explicitly started to perform the sort).

Ultimately one problem with most windows abstraction frameworks is you still
need to understand what is going on underneath the covers in order to use
the framework effectively.

Hope this helps.
 
Hi Me and or Kevin,

Thanks for your replies. I have a follow up question.

If button clicks, for instance, are being handled one at a time, then
what about other events I am subscribed to such as delegate call backs
from a web service or a message arrived event in MSMQ?
 
Coder said:
Hi Me and or Kevin,

Thanks for your replies. I have a follow up question.

If button clicks, for instance, are being handled one at a time, then
what about other events I am subscribed to such as delegate call backs
from a web service or a message arrived event in MSMQ?
Click to expand...

Callbacks like that are usually executed in thread-pool threads, not in
the UI thread.
 
Jon Skeet said:
Callbacks like that are usually executed in thread-pool threads, not in
the UI thread.
Click to expand...

Which means that if they need to access the UI the should check the
InvokeRequired property on a Control/Form and if required exceute the action
using Invoke or BeginInvoke on a Control/Form - this will cause the delegate
you create to be pushed onto a queue and removed and executed by the UI
thread
 
Back
Top