It seems to me that some people are putting the main thread to sleep for no good reason, and Im wondering if there is a point in doing that?
Say one is reading an AD pin in a loop and flashing an LED at a given threshold and thats all thats going on. Is there any point in putting that in its own thread and putting the main thread to sleep?
I suppose its a windows thing…
We do the same in embedded world with “while(1);” , then let the interrupts take over!
If the AtoD is in one thread ( doing what it does best ) why keep the main thread running!
Maybe it’ll use less power?
Cheers Ian
Good question ! 
As IanR is suggesting, maybe it has something to do with power consumption ? If the main thread is not sleeping, maybe it always draws some more power ?
I also would like to understand the internals of this :think:
I have no problem with a setup where the Main thread is used to set up event handlers and then is put to sleep.
But is there a point of starting a new thread for something that could be handled inside the Main thread, just for the sake of putting the main thread to sleep?
As i understand GC will the Main thread never dye and be handled by GC to free up resources, so what is the point of not using it?
This was maybe a strange thread to start, but I’m just wandering. 
There might be some benefits in doing so, but they would be related to how the netmf is handled on the device.
But if you really think about this, the biggest benefit you get here is that you have a very clear program logic. Set up every thing you need to be “autonomous”, ie in it’s own thread, and on start up the app just need to invoke the necessary threads and set them on their way. One thing I see that by making this the usual way you approach a problem means if you come back and extend functionality (scope creep, without design? never! ) you might find it simpler to shoe-horn a new thread in rather than inject code into a mainline.
“main” method should never exit as this will end everything. So if you are not using “main” for your loop then what do you do? While(true) is an extreme bad idea as it uses processor time doing nothing. The only option left is sleep(-1)
I’ve programmed a lot of things over the years and I’ve become very cautious about killing an application anywhere other than in the main thread. I’m no expert at .NET and its GC, so I have no idea just how careful you have to be when you’re using it.
When I do use threading (coroutines, whatever), I usually reserve the main thread to at least handle the polling - or whatever other method you want to use - that handles closing down the app. That way, if the trash collector is working ‘properly’ it’ll know what the child processes were, and if the OS trash collection is lousy, you have an orderly way (and sane location) to kill the child threads,
If you use software signalling or whatever, that’s the place to put the watchdog routines that can disable hardware, sensors, clean down memory etc before an orderly exit(0). I know that there are all sorts of benefits to running a fully interrupt driven codebase, but sometimes, I think it’s valuable to come back to see whether your heap’s full and you need to recover space explicitly.
I know it sounds rather dictatorial, but it’s how I’ve always done it, and whenever I didn’t follow my own rules, I often ended up regretting it.
What you are saying Mog makes lot of sense on a desktop application but on these devices there usually have no graceful exit, its just pull the plug and everything is off.
Ive been using Arduino for a log application writing to a SD card. If one pulled the plug when it was writing one could end up with either a useless log file or in the worst case a useless SD card. I dont know if FEZ has the same problem, but there should be a way to have say a 1 second UPS so the application could shut down gracefully.
An no, I have absolutely no idea how such a feature could be implemented (unless one have a battery on the RTC)
Well, yeah, for the most part, these were loggers and DAQ devices hooked up to machines with switchmode power supplies etc, so I had the ‘luxury’ of setting CTS on serial lines, flushing file buffers etc.
But the point you raise is an interesting one. How about a hardware project to build exactly that kind of ‘UPS’ that provides a few seconds of power autonomy with a power fail sensor. Could you maybe do it with a simple transistor circuit and an electrolytic capacitor? 2 seconds would be plenty of time to detect a power drop and flush a filesystem. It’s not like it would need to supply more than 3A/sec of power.
Taking into consideration some of the conversations in other threads concerning poor power conditioning from wall warts, it sounds like this might be beneficial there too. Anyone feel like volunteering?
There is no reason you “have” to put main to sleep as long as you can do useful work. If all your other stuff is event driven, then main would eventually have to sleep or loop waiting on work. However, if you need to poll sensors (maybe not all event driven) then no reason you should not loop in main (or in a method called in main), then just fall out when your app ends (e.g. stop your robot).
Main in a console app is like the UI thread without the message pump in a windows app. Naturally, main has no message pump or queue, but that does not mean you could not add something like that and read on a blocking queue http://www.fezzer.com/project/107/blocking-queue/ in a loop. Not a bad pattern as it has been around a long time.