In the current code, the only components which start RT threads are motion (motmod) and threads the only components which stop threads are hal_lib and motmod
they differ as follows: - unloading 'motmod' stops all threads - unloading 'hal_lib' stops all threads - unloading 'threads' does _not_ stop threads so using the latter you can have RT threads running without either motmod or threads loaded Intuitively I would say if I look at halcmd comp output and see neither threads or motmod loaded but thread functions actually called and maybe hardware moving that is confusing. It really rests on a definition, namely whether threads are 'owned' by a module, and if so, which one(s); meaning unloading that module stops threads, or not. HAL does stop threads on exit, which suggests threads are 'owned' by HAL; in which case motmod is inconsistent with that definition. Barring other suggestions, I will change threads to conform with motmod - that is, stop threads on unload, which I think is safe. I know barely anybody uses the threads module so that's likely safe but I'm raising it more to clarify semantics than to cry wolf. I dont care one way or the other, but a concise definition of thread ownership of modules, and consistent behavior would be a plus. -Michael --- background: work on the unified binary is underway, and it looks now we can actually have a single build running on RTAI, Xenomai, RT-PREEMPT or vanilla kernels (simulator mode) eventually, which would alleviate the need for separate sim and RT builds. As a tribute to the strength of the HAL/RTAPI design I must say the changes are negligible and of the 'touchoff' category. Part of that work is merging the execution paths of RT and sim builds, which will mean that helper programs like module_helper and rtapi_app are replaced by an RTAPI demon. This will be the single locus of loading/unloading RT modules kernel or userland style, of privilege management, home of userland RT threads, and startup/shutdown sequencing, and hence a single location of bugs which is currently distributed over halcmd, scripts/realtime and rtapi_app. Looking into the common shutdown sequence triggered the above question. rtapid currently uses LGPL3 code (intra HAL/RTAPI). I hope we will be able to resolve that licensing issue at least in the limited HAL/RTAPI space with a tangible result. If anybody has suggestions for integrator configurable shutdown/emergency shutdown handling I'd be interested to hear about them. ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
