Note that the documentation is often misleading - there are plenty of classes
in the framework that claim to be using threads or the thread pool when they're
actually doing intrinsically asynchronous calls as Mike describes.
--
Ian Griffiths
From: Unmoderat
@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] MessageQueue and Thread
> Interesting. I thought as soon as you call BeginReceive or
> any Beginxxx, a
> ThreadPool thread is used to actually do the receive or any
> work. I need to
> look more into the idea.
Depends on exactly which Begi
> I'm worried that if the actual receive is done on a
> ThreadPool thread, then
> when we want to stop, the actual receive is still going on, which will
> remove the message from the queue without our knowledge
> (since we already
> shut down), thus resulting in lost message. I think that
> problem
>Why is the implementation of BeginReceive so crucial to your situation? Or
>are you just trying to pick it apart to satisfy your curiosity?
I'm worried that if the actual receive is done on a ThreadPool thread, then
when we want to stop, the actual receive is still going on, which will
remove th
> Interesting. I thought as soon as you call BeginReceive or
> any Beginxxx, a
> ThreadPool thread is used to actually do the receive or any
> work. I need to
> look more into the idea.
Depends on exactly which BeginXxx method you called. Each implementation
supports the async pattern in the most
Interesting. I thought as soon as you call BeginReceive or any Beginxxx, a
ThreadPool thread is used to actually do the receive or any work. I need to
look more into the idea.
Thank you very much.
Tong
===
This list is hosted by DevelopMentor® http://www.develop.
> I'm exploring ways to control receive from MessageQueue.
> Async receive runs
> on a ThreadPool Thread and thus cannot be controlled.
You can do async receives w/o involving the threadpool if you want:
using System;
using System.Threading;
using System.Messaging;
class ThreadTest
{
public
The common pattern here, then, would be to receive to TImeSpan.Zero,
and then sleep for a short period of time while waiting on an event
which is signaled for shutdown.
On Wed, 23 Mar 2005 00:27:04 -0500, Tong <[EMAIL PROTECTED]> wrote:
> I'm exploring ways to control receive from MessageQueue. As
I'm exploring ways to control receive from MessageQueue. Async receive runs
on a ThreadPool Thread and thus cannot be controlled.
Anyway, thanks.
Tong
===
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s)
> I don't know what I did wrong. Somehow, I just cannot seem to
> use the Close
> queue approach to get the Receive call unstuck. Here is a
> trivial test. Any
> idea?
Nope - it looks like pulling the rug out from under the receiver thread flat
out doesn't work like I thought it would. Must have
Tong
Sent: Tuesday, March 22, 2005 4:50 PM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: Re: [ADVANCED-DOTNET] MessageQueue and Thread
Hi Mike,
Thanks for the rather enlightening explanation.
I don't know what I did wrong. Somehow, I just cannot seem to use the Close
queue approach to ge
Hi Mike,
Thanks for the rather enlightening explanation.
I don't know what I did wrong. Somehow, I just cannot seem to use the Close
queue approach to get the Receive call unstuck. Here is a trivial test. Any
idea?
Thanks.
Tong
class ThreadTest
{
public static void Run()
> When I try to
> cancel the thread using Thread.Abort() method, the thread
> stays alive. Isn't
> Thread.Abort() supposed to stop the thread no matter what it
> is doing?
Thread.Abort is only a best-effort attempt to abort the thread. But if (for
example) the target thread has left managed execu
I found a strange behavior regarding MessageQueue and Thread that some one
with more experience might shed some light on.
In my ThreadStart delegate method, I have a mq.Receive() call. I know it's
thread blocking. However, it seems to be more than that. When I try to
cancel the thread using Thread
14 matches
Mail list logo
