9 replies to this topic

[sebastianpatten]

I'm doing some code for my NetDuino Plus to act as a web server. So basically right now I put a request to http://localhost:8080 and its responding with a 200 OK - Hello World.

Im building and testing this using the emalator. Without a while(true) the application quits. Is this what I should be doing? Is there a better way to keep the program running and not just drop out?

Thanks!

using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoPlus;
using MFToolkit.Net.Web;

namespace WebServer
{
    public class Program
    {
        public static void Main()
        {
            using (HttpServer httpServer = new HttpServer(8080, new MyHttpHandler()))
            {
                httpServer.Start();
            }
        }
    }

    public class MyHttpHandler : IHttpHandler
    {
        public void ProcessRequest(HttpContext context)
        {
            BuildHttpResponse(context.Response);
        }

        public void BuildHttpResponse(HttpResponse httpResponse)
        {
            httpResponse.HttpStatus = HttpStatusCode.OK;
            httpResponse.WriteLine("Hello World");
        }
    }
}

[Dan Morphis]

Im building and testing this using the emalator. Without a while(true) the application quits. Is this what I should be doing? Is there a better way to keep the program running and not just drop out?

Thread.Sleep(Timeout.Infinite);

Will work great.

[sebastianpatten]

Yes this works. It looks nicer too. Thanks.

[Mark H]

while (true) is bad to use (Thread.Sleep is the correct way) because it is basically keeping the CPU doing something constantly. This makes it so that other threads may be delayed in getting access to processor time giving you a slow response and also doesn't let the chip go into a power saving mode.

[Luke Cummings]

There is another way to grab execution without requiring the checking of a while, try this:

for(;;);

It looks funny but if you think about how a for loop works you can see how this basically turns into a looping nop instruction.

That said since you are dealing with an interpreted language I'm not sure if this would actually turn into an infinitely looping nop instruction like it would in c.

This makes it so that other threads may be delayed in getting access to processor time giving you a slow response and also doesn't let the chip go into a power saving mode.

It shouldn't delay any other threads as the processor is always doing "something" nop's or otherwise, but you're correct that it will increase power consumption.

Edit: This statement is unverifiably vauge

[Mark H]

It actually does delay other threads, try it Other threads will wait up to 5ms depending on their thread priority.

[Miha Markic]

It actually does delay other threads, try it Other threads will wait up to 5ms depending on their thread priority.

Any loop will cause CPU to work 100%. Even if it is doing NOPs it will do that all the time. I guess placing Thread.Sleep(something) statements within the loop will greatly reduce the CPU utilization.
However, as previously stated, avoid the loops if they are not necessary.

[Chris Walker]

Yup, Mark speaks the truth.

An empty while(true) loop (or for(;;) will basically create a thread which executes an infinite number of nop and loop instructions.

Since .NET Micro Framework is a cooperative multitasking framework, the thread scheduler will happily give the while(true) thread a big chunk of execution time (up to 20ms) before taking execution away and awarding it to another thread.

If you want to put a thread to sleep forever (particularly your main thread), use:

Thread.Sleep(Timeout.Infinite);

Chris

[Fred]

I tend to go for a middle ground of:

while (true)
  Thread.Sleep(10000);

I just have a feeling that if you're debugging it gives Visual Studio a chance to interrupt execution every 10s. I have to say I can't really justify it any better than that though!

[Chris Walker]

I tend to go for a middle ground of:

while (true)
  Thread.Sleep(10000);

I just have a feeling that if you're debugging it gives Visual Studio a chance to interrupt execution every 10s. I have to say I can't really justify it any better than that though!

Hi Fred,

Unless there's a bug in the .NET MF firmware which disables the thread scheduler, the Visual Studio debugger should get a timeslice along with the other threads (and the repeated 10 sec sleep won't have any notice-able effect).

That said, you're welcome to use whatever feels natural...

Chris