Thread.Sleep...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

Currently I have a thread thats spinning and doing a
Thread.Sleep(someTime).

I was thinking of changing this to Thread.Sleep(Timeout.Infinite); then
when I have actual data in a collection to process in this thread, I was
going to do a _thread.Interrupt(); Would this be a better approach to
spinning a thread on ?

A better approach still would be to use Monitor.Wait and Monitor.Pulse.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jon,
how long you been writing thread code?

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

Currently I have a thread thats spinning and doing a
Thread.Sleep(someTime).

I was thinking of changing this to Thread.Sleep(Timeout.Infinite); then when I have actual data in a collection to process in this thread, I was
going to do a _thread.Interrupt(); Would this be a better approach to
spinning a thread on ?

A better approach still would be to use Monitor.Wait and Monitor.Pulse.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

You can use the Q.Sychronized wrapper and not have to use lock(q) blah

The only time u need to use the lock(q) is when you are using IEnumerator as
its intrisincally blah cant spell not thread safe.

So the simpler approach in a code base would be to sleep infinte and then
interrupt that.

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:eZ**************@TK2MSFTNGP09.phx.gbl...

Jon,
how long you been writing thread code?

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

Currently I have a thread thats spinning and doing a
Thread.Sleep(someTime).

I was thinking of changing this to Thread.Sleep(Timeout.Infinite); then when I have actual data in a collection to process in this thread, I was going to do a _thread.Interrupt(); Would this be a better approach to spinning a thread on ?

A better approach still would be to use Monitor.Wait and Monitor.Pulse.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

IF you need to use lock on a colleciton object you use the SynRoot. Why
bother with all that Monitor stuff and lock when you dont need to?
"news.microsoft.com" <di********@discussion.microsoft.com> wrote in message
news:u1**************@TK2MSFTNGP10.phx.gbl...

You can use the Q.Sychronized wrapper and not have to use lock(q) blah

The only time u need to use the lock(q) is when you are using IEnumerator as its intrisincally blah cant spell not thread safe.

So the simpler approach in a code base would be to sleep infinte and then
interrupt that.

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:eZ**************@TK2MSFTNGP09.phx.gbl...

Jon,
how long you been writing thread code?

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:
> Currently I have a thread thats spinning and doing a
> Thread.Sleep(someTime).
>
> I was thinking of changing this to Thread.Sleep(Timeout.Infinite);

then

> when I have actual data in a collection to process in this thread, I was > going to do a _thread.Interrupt(); Would this be a better approach to > spinning a thread on ?

A better approach still would be to use Monitor.Wait and Monitor.Pulse.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

I dont want it to be spinning all the time at 100% CPU, i want it to rest
then once its interrupted, to start to spin a predefined cycle rate using
Sleep(blah) then once its empty, to go infinite again.
"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:eZ**************@TK2MSFTNGP09.phx.gbl...

Jon,
how long you been writing thread code?

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

Currently I have a thread thats spinning and doing a
Thread.Sleep(someTime).

I was thinking of changing this to Thread.Sleep(Timeout.Infinite); then when I have actual data in a collection to process in this thread, I was going to do a _thread.Interrupt(); Would this be a better approach to spinning a thread on ?

A better approach still would be to use Monitor.Wait and Monitor.Pulse.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

You're right that the Thread.Interrupt() approach is better than a
Thread.Sleep(someTime) loop. The only thing is that as I'm sure you know,
Thread.Interrupt() causes an exception to be thrown on the specified
thread... not really a problem if you catch it, but from what I read,
throwing/catching exceptions over and over again is a somewhat expensive and
inefficient thing to do.

Perhaps try a more traditional approach: Create an AutoResetEvent object
and have your worker thread call Wait() against that event object. The
thread then goes to Sleep (0% CPU utilization) until the event is "signaled"
by another thread. So when your program determines that there is work to be
done, it signals the event (see AutoResetEvent.Set()) and your worker thread
instantly "wakes up" to do its thing.

David

"news.microsoft.com" <di********@discussion.microsoft.com> wrote in message
news:O4**************@TK2MSFTNGP10.phx.gbl...

Hi,

Currently I have a thread thats spinning and doing a
Thread.Sleep(someTime).

I was thinking of changing this to Thread.Sleep(Timeout.Infinite); then
when I have actual data in a collection to process in this thread, I was
going to do a _thread.Interrupt(); Would this be a better approach to
spinning a thread on ?

Alvin Bruney <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote:

how long you been writing thread code?

A fair time - why?

I'm suggesting Monitor.Wait/Pulse because they (along with
Manual/AutoResetEvents) are specifically designed for exactly this kind
of thing.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

a fair time? what's that 2 days? 2 months? 2 years?
am asking when you started to actually write it, not when you first knew it
existed or heard about it.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP**********************@msnews.microsoft.com ...

Alvin Bruney <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote:

how long you been writing thread code?

A fair time - why?

I'm suggesting Monitor.Wait/Pulse because they (along with
Manual/AutoResetEvents) are specifically designed for exactly this kind
of thing.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Alvin Bruney <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote:

a fair time? what's that 2 days? 2 months? 2 years?
Longer than that.
am asking when you started to actually write it, not when you first knew it
existed or heard about it.

*Started* to write stuff using threads? About 9 years ago, when I first
started writing Java. Started thinking seriously about it and really
examining things carefully? About 4 years ago.

Again I ask: why do you want to know?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

As some others have pointed out, the best method to use is to wait on an
event to be signalled. A thread that is blocked waiting on an event consumes
0 cpu cycles. Using a spin-wait is the absolute worst way to wait for work
to arrive as it consumes lots of cpu cycles while producing nothing of
value. Using a thread-interrupt is better but not much. In general you
should use synchronization primitives (events, mutexes, semaphores, etc) to
synchronize access to shared resources, and execution control primitives
(suspend/resume/sleep) to control the execution state of a thread. It is
usually extremely rare that user-mode code needs to actually control the
execution state of a thread and very common to need to control the
synchronization of threads to a shared resource.
"news.microsoft.com" <di********@discussion.microsoft.com> wrote in message
news:O4**************@TK2MSFTNGP10.phx.gbl...

Hi,

Currently I have a thread thats spinning and doing a
Thread.Sleep(someTime).

I was thinking of changing this to Thread.Sleep(Timeout.Infinite); then
when I have actual data in a collection to process in this thread, I was
going to do a _thread.Interrupt(); Would this be a better approach to
spinning a thread on ?

> Again I ask: why do you want to know?
it is just soooo discouraging, that's all.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Alvin Bruney <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote:

a fair time? what's that 2 days? 2 months? 2 years?

Longer than that.

am asking when you started to actually write it, not when you first knew it existed or heard about it.

*Started* to write stuff using threads? About 9 years ago, when I first
started writing Java. Started thinking seriously about it and really
examining things carefully? About 4 years ago.

Again I ask: why do you want to know?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

I used the AutoResetEvent.Set to signal the worker thread and
AutoResetEvent.WaitOne() to put it to sleep.

I dont see the need for Monitor.Wait and Monitor.Pulse as the shared item is
already using the synchronised wrapper.

I still have a spin wait so its working on the items at a good pace and not
burning the CPU from other more important threads. Is it possible to
prioritise threads?

"David Sworder" <ds******@cts.com> wrote in message
news:ug**************@tk2msftngp13.phx.gbl...

You're right that the Thread.Interrupt() approach is better than a
Thread.Sleep(someTime) loop. The only thing is that as I'm sure you know,
Thread.Interrupt() causes an exception to be thrown on the specified
thread... not really a problem if you catch it, but from what I read,
throwing/catching exceptions over and over again is a somewhat expensive and inefficient thing to do.

Perhaps try a more traditional approach: Create an AutoResetEvent object and have your worker thread call Wait() against that event object. The
thread then goes to Sleep (0% CPU utilization) until the event is "signaled" by another thread. So when your program determines that there is work to be done, it signals the event (see AutoResetEvent.Set()) and your worker thread instantly "wakes up" to do its thing.

David

"news.microsoft.com" <di********@discussion.microsoft.com> wrote in message news:O4**************@TK2MSFTNGP10.phx.gbl...

Hi,

Currently I have a thread thats spinning and doing a
Thread.Sleep(someTime).

I was thinking of changing this to Thread.Sleep(Timeout.Infinite); then when I have actual data in a collection to process in this thread, I was
going to do a _thread.Interrupt(); Would this be a better approach to
spinning a thread on ?

news.microsoft.com <di********@discussion.microsoft.com> wrote:

I used the AutoResetEvent.Set to signal the worker thread and
AutoResetEvent.WaitOne() to put it to sleep.

I dont see the need for Monitor.Wait and Monitor.Pulse as the shared item is
already using the synchronised wrapper.
You're certainly only like to need *either* AutoResetEvent *or*
Monitor.Wait/Pulse, but I don't see why using a synchronised wrapper
would knock Monitor.Wait/Pulse out of the equation.
I still have a spin wait so its working on the items at a good pace and not
burning the CPU from other more important threads.
I don't think a spin wait is a particularly good way of doing that
though - why not just sleep briefly? IIRC, the purpose of spin waits is
to wait *without* yielding to another thread, if you have a good reason
to believe that the reason you're unwilling to do more work is about to
be removed, as it were.
Is it possible to prioritise threads?

Sort of - have a look at the Thread.Priority property. Note that it
doesn't have to be honoured.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

I only spin wait if the .Count is positive. so its processing at a regular
frequency. Its only doing Wait once its empty. Likely this shared
collection will come in bursts.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

I used the AutoResetEvent.Set to signal the worker thread and
AutoResetEvent.WaitOne() to put it to sleep.

I dont see the need for Monitor.Wait and Monitor.Pulse as the shared item is already using the synchronised wrapper.

You're certainly only like to need *either* AutoResetEvent *or*
Monitor.Wait/Pulse, but I don't see why using a synchronised wrapper
would knock Monitor.Wait/Pulse out of the equation.

I still have a spin wait so its working on the items at a good pace and not burning the CPU from other more important threads.

I don't think a spin wait is a particularly good way of doing that
though - why not just sleep briefly? IIRC, the purpose of spin waits is
to wait *without* yielding to another thread, if you have a good reason
to believe that the reason you're unwilling to do more work is about to
be removed, as it were.

Is it possible to prioritise threads?

Sort of - have a look at the Thread.Priority property. Note that it
doesn't have to be honoured.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

When I said spinwait i meant a Thread.Sleep(Frequency); not per iteration
as in SpinWait(N);

Maybe a bad choice of terminology.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

I used the AutoResetEvent.Set to signal the worker thread and
AutoResetEvent.WaitOne() to put it to sleep.

I dont see the need for Monitor.Wait and Monitor.Pulse as the shared item is already using the synchronised wrapper.

You're certainly only like to need *either* AutoResetEvent *or*
Monitor.Wait/Pulse, but I don't see why using a synchronised wrapper
would knock Monitor.Wait/Pulse out of the equation.

I still have a spin wait so its working on the items at a good pace and not burning the CPU from other more important threads.

I don't think a spin wait is a particularly good way of doing that
though - why not just sleep briefly? IIRC, the purpose of spin waits is
to wait *without* yielding to another thread, if you have a good reason
to believe that the reason you're unwilling to do more work is about to
be removed, as it were.

Is it possible to prioritise threads?

Sort of - have a look at the Thread.Priority property. Note that it
doesn't have to be honoured.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

AutoResetEvent Just made more sense to me than Monitor.Wait and .Pulse, both
would be doing the same job here so what are the benifits of
Monitor.Wait/Pulse over AutoResetEvent?
"news.microsoft.com" <di********@discussion.microsoft.com> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...

When I said spinwait i meant a Thread.Sleep(Frequency); not per iteration
as in SpinWait(N);

Maybe a bad choice of terminology.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

I used the AutoResetEvent.Set to signal the worker thread and
AutoResetEvent.WaitOne() to put it to sleep.

I dont see the need for Monitor.Wait and Monitor.Pulse as the shared item is already using the synchronised wrapper.
You're certainly only like to need *either* AutoResetEvent *or*
Monitor.Wait/Pulse, but I don't see why using a synchronised wrapper
would knock Monitor.Wait/Pulse out of the equation.

I still have a spin wait so its working on the items at a good pace

and not burning the CPU from other more important threads.

I don't think a spin wait is a particularly good way of doing that
though - why not just sleep briefly? IIRC, the purpose of spin waits is
to wait *without* yielding to another thread, if you have a good reason
to believe that the reason you're unwilling to do more work is about to
be removed, as it were.

Is it possible to prioritise threads?

Sort of - have a look at the Thread.Priority property. Note that it
doesn't have to be honoured.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

news.microsoft.com <di********@discussion.microsoft.com> wrote:

When I said spinwait i meant a Thread.Sleep(Frequency); not per iteration
as in SpinWait(N);
Ah, right. A spin wait is very different - it's a way of saying, "Keep
yourself busy, but don't actually do anything useful, just for a little
bit." Thread.Sleep is fine.
AutoResetEvent Just made more sense to me than Monitor.Wait and .Pulse, both
would be doing the same job here so what are the benifits of
Monitor.Wait/Pulse over AutoResetEvent?

I don't know that there are any, other than that Monitor.Wait/Pulse are
less .NET/Windows-specific concepts. They act in slightly different
ways, but I don't know enough detail about what you want to know which
would be better.

I tend to prefer Monitor.Wait/Pulse/PulseAll as they're very similar to
Java's Object.Wait/Notify/NotifyAll. Just personal preference, really.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

I think most people are familiar with the concept of AutoResetEvents more
than monitor pulse and wait so its even more readable. Both achieve the
same effect as far as I can see except Monitor takes a lock on the object
and autosetevent does not. Its just an event really. Since the item is
already synchronised I was more concerned about taking another lock on that
object with Monitor.Wait/Pulse.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

When I said spinwait i meant a Thread.Sleep(Frequency); not per iteration as in SpinWait(N);

Ah, right. A spin wait is very different - it's a way of saying, "Keep
yourself busy, but don't actually do anything useful, just for a little
bit." Thread.Sleep is fine.

AutoResetEvent Just made more sense to me than Monitor.Wait and .Pulse, both would be doing the same job here so what are the benifits of
Monitor.Wait/Pulse over AutoResetEvent?

I don't know that there are any, other than that Monitor.Wait/Pulse are
less .NET/Windows-specific concepts. They act in slightly different
ways, but I don't know enough detail about what you want to know which
would be better.

I tend to prefer Monitor.Wait/Pulse/PulseAll as they're very similar to
Java's Object.Wait/Notify/NotifyAll. Just personal preference, really.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

news.microsoft.com <di********@discussion.microsoft.com> wrote:

I think most people are familiar with the concept of AutoResetEvents more
than monitor pulse and wait so its even more readable.
That really depends on their background. If they're Java programmers
they'll be more familiar with monitors and waiting/notifying them. If
they're Win32 programmers they're probably more familiar with
AutoResetEvents.
Both achieve the
same effect as far as I can see except Monitor takes a lock on the object
and autosetevent does not. Its just an event really. Since the item is
already synchronised I was more concerned about taking another lock on that
object with Monitor.Wait/Pulse.

You don't have to use that particular object though - I usually
advocate using a separate object specifically for locking/waiting etc.
The cost of taking out a lock is pretty small, especially when
uncontested.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Normally for using collections one uses the provided .SynRoot property thats
there for that task. If you look at the examples for IEnumerable on
collecitons thats what it uses. collectionObj.SynRoot

Still, I like to keep locks to a minimum and I dont see a need for a lock
there on an already synchronized object so AutoResetEvents seemed to me to
be more appropriate.

Being a win32 coder , AutoResetEvents makes more sense to me as you point
out.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

news.microsoft.com <di********@discussion.microsoft.com> wrote:

I think most people are familiar with the concept of AutoResetEvents more than monitor pulse and wait so its even more readable.

That really depends on their background. If they're Java programmers
they'll be more familiar with monitors and waiting/notifying them. If
they're Win32 programmers they're probably more familiar with
AutoResetEvents.

Both achieve the
same effect as far as I can see except Monitor takes a lock on the object and autosetevent does not. Its just an event really. Since the item is
already synchronised I was more concerned about taking another lock on that object with Monitor.Wait/Pulse.

You don't have to use that particular object though - I usually
advocate using a separate object specifically for locking/waiting etc.
The cost of taking out a lock is pretty small, especially when
uncontested.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

To Alvin.

What's up with u dude - are you just a part-time ass or what? I
noticed ur stupid post towards someone who asked a question regarding
NGEN in one of the other .NET groups, as well as the rubbish ur
posting to Jon Skeet in this thread.

If you have something funny to say, then say it. If you have sod all
useful to say - look into a mirror and tell it to the only person who
cares.

I've seen other posts by you where you have actually helped a lot of
people, why do you then insist on posting crap at other times? There's
always one I guess.......

news.microsoft.com <di********@discussion.microsoft.com> wrote:

Normally for using collections one uses the provided .SynRoot property thats
there for that task. If you look at the examples for IEnumerable on
collecitons thats what it uses. collectionObj.SynRoot
Yes, SyncRoot is fine for that purpose, but it's often nice to have
separate monitors specifically for thread waiting/notification. It just
makes life a bit easier to understand (IMO) and threading is a very
hard thing to get right to start with.
Still, I like to keep locks to a minimum and I dont see a need for a lock
there on an already synchronized object so AutoResetEvents seemed to me to
be more appropriate.

Being a win32 coder , AutoResetEvents makes more sense to me as you point
out.

You should be aware that AutoResetEvents almost certainly use their own
locks internally - I'd be very surprised if they were actually
significantly more efficient than using Monitor.Wait/Pulse. I'm not
saying you shouldn't use them - it's a matter of personal preference,
as I've said, and your last reason makes a lot of sense, but I wouldn't
focus too much on not having many locks. Making sure that you only lock
what you need to is more important, and that usually involves having
*more* locks available, to make each one finer-grained.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

NGEN? Can you post this so called thread so I can take a look at it.

NGEN in one of the other .NET groups, as well as the rubbish ur
posting to Jon Skeet in this thread.
What gives you the right to jump in here and declare it was rubbish? I have
solid reasons for posting a question like this. May be you should ask before
taking a shot eh?

My reason for posting this

Again I ask: why do you want to know?

it is just soooo discouraging, that's all.

was because I am feeling rather inadequate with my thread knowledge. I was
simply wanting to know if I needed to keep working in the pursuit of
increasing this knowledge or whether I should give it up and do something
else with my life. As he said, it took him a while to get there. I'm not
there yet. That is why it is discouraging to me. I wasn't going to reply to
your bullshit because I didn't think I was being a half ass. You could have
just asked instead of jumping the gun.

And by the way, an individual calling himself Jack Mayoff has been spoofing
my email account (and others by the way) replying to threads in my name. I
haven't caught all his attempts but you may be referring to one of his. I
wont give you the benefit of the doubt either. In short, if you follow my
post, it is rather easy to differentiate between me and a wanna be. But then
again, you couldn't get this last one so go figure.

shall we say an apology is in order? preach, do you think i was being a half
ass?
--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
<Curious> wrote in message news:3f***************@news.microsoft.com...
To Alvin.

What's up with u dude - are you just a part-time ass or what? I
noticed ur stupid post towards someone who asked a question regarding
NGEN in one of the other .NET groups, as well as the rubbish ur
posting to Jon Skeet in this thread.

If you have something funny to say, then say it. If you have sod all
useful to say - look into a mirror and tell it to the only person who
cares.

I've seen other posts by you where you have actually helped a lot of
people, why do you then insist on posting crap at other times? There's
always one I guess.......

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:el*************@TK2MSFTNGP12.phx.gbl...

NGEN? Can you post this so called thread so I can take a look at it.

NGEN in one of the other .NET groups, as well as the rubbish ur
posting to Jon Skeet in this thread.
What gives you the right to jump in here and declare it was rubbish? I

have solid reasons for posting a question like this. May be you should ask before taking a shot eh?
I have solid crap in my toilet.
My reason for posting this

Again I ask: why do you want to know?it is just soooo discouraging, that's all.

was because I am feeling rather inadequate with my thread knowledge. I was
simply wanting to know if I needed to keep working in the pursuit of
increasing this knowledge or whether I should give it up and do something
else with my life. As he said, it took him a while to get there. I'm not
there yet. That is why it is discouraging to me. I wasn't going to reply

to your bullshit because I didn't think I was being a half ass. You could have just asked instead of jumping the gun.

And by the way, an individual calling himself Jack Mayoff has been spoofing my email account (and others by the way) replying to threads in my name. I
haven't caught all his attempts but you may be referring to one of his. I
wont give you the benefit of the doubt either. In short, if you follow my
post, it is rather easy to differentiate between me and a wanna be. But then again, you couldn't get this last one so go figure.

shall we say an apology is in order? preach, do you think i was being a half ass?
--

No I don't think you were being a "half ass" I think you area a "complete
ass".

-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
<Curious> wrote in message news:3f***************@news.microsoft.com...

To Alvin.

What's up with u dude - are you just a part-time ass or what? I
noticed ur stupid post towards someone who asked a question regarding
NGEN in one of the other .NET groups, as well as the rubbish ur
posting to Jon Skeet in this thread.

If you have something funny to say, then say it. If you have sod all
useful to say - look into a mirror and tell it to the only person who
cares.

I've seen other posts by you where you have actually helped a lot of
people, why do you then insist on posting crap at other times? There's
always one I guess.......

Yo.

Ahhh, well in that case it seems that indeed I was in the wrong. I
guess it was one of those days and I needed to get some steam out.

Having read some of your earlier posts and then reading "your" reply
to:

NGEN microsoft system dlls? by Bob Whiton in
microsoft.public.dotnet.performance

I thought hang on, that's a bit out of order.

Again, appologies for jumping the gun there - never meant to upset you
in any way. I would feel bad if I did annoy you.

All the best dude.

'The mistakes of others are good teachers'. Proverb.

It's all good. No hard feelings.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
<Curious> wrote in message news:3f****************@news.microsoft.com...

Yo.

Ahhh, well in that case it seems that indeed I was in the wrong. I
guess it was one of those days and I needed to get some steam out.

Having read some of your earlier posts and then reading "your" reply
to:

NGEN microsoft system dlls? by Bob Whiton in
microsoft.public.dotnet.performance

I thought hang on, that's a bit out of order.

Again, appologies for jumping the gun there - never meant to upset you
in any way. I would feel bad if I did annoy you.

All the best dude.

'The mistakes of others are good teachers'. Proverb.