Prev: System.Net.Sockets.Socket question
Next: FileInfo.CopyTo to a mapped or network drive
From: Julie on 22 Jan 2010 15:52
Perhaps, if I get null, then I can sleep; and if I don't get null, I
won't sleep(?).

From: Julie on 22 Jan 2010 15:58
On Jan 22, 12:52 pm, Julie <julievogelm...(a)gmail.com> wrote:
> Perhaps, if I get null, then I can sleep; and if I don't get null, I
> won't sleep(?).

Awesome! I just implemented this, and the CPU's no longer at 100%!

Thanks, everyone, for your ideas.
From: Peter Duniho on 22 Jan 2010 16:06
Julie wrote:
> But what if the client takes a break from sending but still has more
> to send? I don't want to stop checking for messages, but I don't want
> to use up CPU either. Hmm...

As you may or may not have figured out by now, there's a big difference
between the end-of-stream, and temporary cessation of data being sent.

If the client "takes a break" by simply not sending more data,
ReadLine() will block. If the client "takes a break" by closing the
connection, then no more data will EVER arrive on that connection, and
ReadLine() will return null. In the latter case, there is no point in
continuing the loop. You'll NEVER see any more data returned by the
ReadLine() method of that instance of StreamReader.

If you have, as you seem to be implying in your subsequent replies,
added a call to Thread.Sleep() to your code, then you have NOT fixed the
problem correctly. You do NOT need Thread.Sleep() in this situation.

Pete
From: Julie on 22 Jan 2010 16:15
On Jan 22, 1:06 pm, Peter Duniho <no.peted.s...(a)no.nwlink.spam.com>
wrote:
> Julie wrote:
> > But what if the client takes a break from sending but still has more
> > to send? I don't want to stop checking for messages, but I don't want
> > to use up CPU either. Hmm...
>
> As you may or may not have figured out by now, there's a big difference
> between the end-of-stream, and temporary cessation of data being sent.
>
> If the client "takes a break" by simply not sending more data,
> ReadLine() will block.  If the client "takes a break" by closing the
> connection, then no more data will EVER arrive on that connection, and
> ReadLine() will return null.  In the latter case, there is no point in
> continuing the loop.  You'll NEVER see any more data returned by the
> ReadLine() method of that instance ofStreamReader.
>
> If you have, as you seem to be implying in your subsequent replies,
> added a call to Thread.Sleep() to your code, then you have NOT fixed the
> problem correctly.  You do NOT need Thread.Sleep() in this situation.
>
> Pete


Ahhh...I didn't realize that null meant the client had closed the
connection. Thanks for the clarification.
From: Julie on 22 Jan 2010 16:20
Okay, so I've implemented what you recommended (only reading for as
long as inputString != null) - looks good! CPU is normal.
First  |  Prev  | 
Pages: 1 2 3
Prev: System.Net.Sockets.Socket question
Next: FileInfo.CopyTo to a mapped or network drive