同样的，rt-thread在main中调用了rtthread_startup(),并可以看出rtthread_startup()调用了启动调度函数rt_system_scheduler_start();并随后给出注释/* never reach here */，也就是说启动器一旦调度成功，是不会也不能返回的（除非所有的任务都结束了）。
也就是说rt-thread的main函数也是不会也不能返回的。
3.其它2个我没有细看，但有理由相信（或请“安”给出一个不相信的理由），COOCS和MQX的实现机理和上述UC/OS和TR-THREAD一样：即，main是不会也不能返回的。
通过查看可知，貌似只有RTX和FreeRTOS有把main作为任务函数的配置项。
LZ是使用了RTOS，但如果osFeature_MainThread没有设置为1，则main是不能也不会停止运行的。
如果osFeature_MainThread设置为了1，则main函数作为一个任务函数的角色出现，这个任务函数是可以停止运行的。
该问题的关键，要看调度器位于什么位置，调度器在main中被调用执行，则main无法停止也不会停止，否则main可以停止。
我没用过这个系统，我用其他的UCOS、COOCS、MQX、rt-thread等系统，main都是作为一个创建任务的功能，可以结束的。
1.根据邵贝贝的《嵌入式实时操作系统uc/os-2》(第二版），3.13节（P113)： UC/OS-II的启动，其中指出了：
“多任务的启动是通过调用OSStart()实现的。”
书中给出了在main中调用OSStart()的示例，而OSStart()又调用了OSStartHighReady()，书中给出了解释：
“OSStartHighReady()将永远不返回到OSStart()。”
我没有在该书和UC/OS的官方网站上找到不在main中调用OSStart()的程序或说明。
也就是说在UC/OS中，main将不会也不能返回！
2.根据rt-Thread官方最新代码，从gitHub中获知：
http://github.com/RT-Thread/real ... lications/startup.c
同样的，rt-thread在main中调用了rtthread_startup(),并可以看出rtthread_startup()调用了启动调度函数rt_system_scheduler_start();并随后给出注释/* never reach here */，也就是说启动器一旦调度成功，是不会也不能返回的（除非所有的任务都结束了）。
也就是说rt-thread的main函数也是不会也不能返回的。
3.其它2个我没有细看，但有理由相信（或请“安”给出一个不相信的理由），COOCS和MQX的实现机理和上述UC/OS和TR-THREAD一样：即，main是不会也不能返回的。
通过查看可知，貌似只有RTX和FreeRTOS有把main作为任务函数的配置项。
我说的可以结束，是main中不去写while(1)。在返回之前他先启动了系统的运行，所以这里实际是跳不出main的。即便是写了while(1),从代码流程上看是会进入while处理，但是他是不会走下去的。
OSStart()，这个是程序运行的关键。
1.你所理解的“结束”不能拿来误导众人，自己娱乐就好了。
2.你所谓的“即便是写了while(1)，从代码流程上看是会进入while处理”（但愿你没有写错且不是你自己娱乐用的句子），是错误的！
你还是未能理解到底哪个是正确的！你到底错在了什么地方！
你的理解停留在了如果有while(1)那么main就结束不了，这个是狭隘且错误的！因为在main中程序是进入不了while(1)的，这跟有没有while(1)都没什么卵用！有while(1)进入不了，没有while(1)，main也不会退出！
那main为什么会退出不去呢？是因为OSStart()（或其他RTOS中表示启动调度的API）是永远不会返回的（除非所有任务都返回了，这种情况程序员是不会故意而为的）！
那main中到底应不应该出现一个while(1)（或者其它任何表示死循环的语句）呢？当然有必要（但不是必须），因为这是预防程序出现错误，万一（注意是万一）从OSStart()返回了，不至于调试代码时不知道程序去哪了？OSStart()万一退出，main函数也就退出了，此时程序返回到重启向量中（一般重启向量的最后一条语句是跳往main函数），PC中已经不存在有意义的指向了，此时系统终止运行。如果main的最后有一个无线循环，那么起码程序员调试时会知道，哦，原来从OSStart()返回了，此时应该注意所有的任务函数是不是有问题。