On Fri, Nov 2, 2012, at 06:11 AM, Michael Haberler wrote:
> > what is the rationale to have _motion_ start threads, if we have a > threads module to start with? this looks entirely unsystematic to me - I > dont understand what's so specific about motion that it just has to do > this. Any other explanation than 'history'? > In EMC1, motmod.c was about 5000 lines and contained almost all of the realtime code. The stuff that is currently part of "motion" was mixed in with the PID blocks and step generation and almsot everything else. Add in a bunch of ifdefs to handle different operating systems, including setting up realtime threads for each OS. Only the one kernel module would get loaded, and it would do everything, with none of the modularity we now have with HAL. So "component creates the threads that it needs" was the historical norm starting in 1995. RTPAI and HAL were both developed before we tackled the rewrite of the motion module. Early in HAL development, almost every component had an insmod time option to create a thread. This was to allow for things like testing the stepper module without loading the motion module. But the underlying mental model for EMC as a whole was still one of having the motion module create the base and servo threads. Motion was still "special", the module around which everything else was built, rather than "just another HAL component". We realized pretty soon that putting "create a thread" code in every HAL module was stupid - hence the "threads" component. But it was (and is) still only used when running HAL outside of a LinuxCNC context, whether that means testing a HAL component, or building a HAL-only machine. When running normal LinuxCNC, motion is still "special". I think one of the reasons that motion still creates the servo and base threads itself is that it made it simple to extract the periods from the ini file and pass them to motion. That code already existed from before (it extracts a bunch of info from the ini file, not just the periods). There are a couple of minor benefits to doing it that way. For one, the average user doesn't even need to know about the "threads" component. Motion handles the "normal" LinuxCNC case of base and servo threads without the user needing to think about it. Another advantage is that motion is less generic than "threads". It knows there are two threads, and it knows that the base thread should be faster than the servo thread. So it can apply some sanity checks to the data from the ini file. None of those advantages are huge, but the impact on the user base (and possible breakage of existing configurations) should be kept in mind when deciding whether or not to change it. -- John Kasunich [email protected] ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
