Re: Fuzzy understanding of asynchronous method calls
From: Steve Sargent (I_hate_spammers_at_spammers_suck.com)
Date: 03/12/04
- Next message: Mike Tinnes: "WM_COPYDATA Win32 -> C#"
- Previous message: Mel: "MSMQ Deserialize"
- In reply to: Nicholas Paldino [.NET/C# MVP]: "Re: Fuzzy understanding of asynchronous method calls"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 12 Mar 2004 00:31:46 GMT
thank you for the answer.
the advice on a different thread is good to consider. the main reason
I used asynchronous methods was so I could pass in parameters. I
could create objects to wrap my threaded functions and pass my
parameters to the object prior to invoking the threaded function. I
will definitely consider that.
As for creating the window in the main thread, the code that creates
the thread is in an event handler called from an outside object, so I
haven't found a way to get that to work properly (and I've tried every
which way) without using the Application.Run call. Also, the new
window form is created from that thread. I've attempted to have the
sub-window form created in the parent window's thread, but this also
has no effect. The window basically pops up for a fraction of a
second and then goes away.
Yes, if there's a cleaner way to have the windows invoked than by
using Application.Run in a separate thread, please let me know. I
would imagine that calling Application.Run numerous times would be
extremely wasteful in resources.
Thanks again for the info.
Steve
On Thu, 11 Mar 2004 10:36:10 -0500, "Nicholas Paldino [.NET/C# MVP]"
<mvp@spam.guard.caspershouse.com> wrote:
>Steve,
>
> No, calling function A on another thread will not block other calls that
>happen asynchronously. If you are using delegates or the thread pool, or
>another thread, each of these will use separate thread instances.
>
> If you are using a thread from the thread pool (either explicitly, or by
>using a delegate and calling BeginInvoke), and running a message pump on
>another thread, then you should change it to use an instance of Thread that
>you create yourself. The reason for this is that it effectively takes a
>thread out of the thread pool, since the call to Run blocks.
>
> Also, running another message loop on another thread isn't very
>conventional. Do you have a specific reason for doing this? Typically, I
>would just call Show on the form and have that run in the main UI thread.
>
> Hope this helps.
>
>
>--
> - Nicholas Paldino [.NET/C# MVP]
> - mvp@spam.guard.caspershouse.com
>
>"Steve Sargent" <I_hate_spammers@spammers_suck.com> wrote in message
>news:40501d2f.10609385@news.microsoft.com...
>> Hi:
>>
>> My understanding of asynchronous method calls is a bit fuzzy. I know
>> they behave similar to threads in a lot of ways, but I'm not
>> comfortable enough with them to feel ok with what i'm doing.
>>
>> right now, I'm envoking a function (function a) asynchronously (the
>> function is OneWay, so as far as I know, it won't block the caller or
>> hose the system if not endinvoked). Inside the function, i'm
>> instantiating a window and calling application.run to set it off.
>> From my understanding, this call blocks the current thread.
>>
>> Will the application.run call from within "function a" prevent other
>> asynchronous calls to function a from being called? "function a" is
>> an event listener and receives many calls.
>>
>>
>> Thank you for any help and advice given.
>>
>> Steve
>
>
- Next message: Mike Tinnes: "WM_COPYDATA Win32 -> C#"
- Previous message: Mel: "MSMQ Deserialize"
- In reply to: Nicholas Paldino [.NET/C# MVP]: "Re: Fuzzy understanding of asynchronous method calls"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
