On Fri, Jan 25, 2013, at 08:06 PM, Michael Haberler wrote:
> 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
To a certain extent I see HAL as a generic platform
for building realtime control systems, one of which
happens to be LinuxCNC.
Any generic control system needs one or more
threads of execution, and the "threads" component
is just a hack to provide a way to create them when
using HAL for something other than LinuxCNC. The
threads created by that component can have any
name(s) and reloading the component is allowed
so that you can create multiple threads incrementally
instead of being stuck with whatever you first
created.
I sometimes use HAL interactively, literally
building a control system one piece at a time,
and I designed it to support that use case.
Ideally the "threads" component wouldn't exist,
and halcmd would simply offer a "newthread"
command, along with "delthread". But there are
(or at least were) complications with doing that,
and the "threads" component was the lazy way out.
If your "HAL daemon" approach would allow a
"newthread" command to work, I think that would
be the best overall approach. But that is only
my opinion.
Motmod creating threads is another hack. Since
LinuxCNC is the most common application that
uses HAL, and since most LinuxCNC users don't
really care about the messy details, motmod creates
the threads it needs automatically. The threads that
motmod creates are always named the same ("base"
and "servo") because that makes things simpler for
LinuxCNC.
If we had a "HAL daemon" with a newthread command,
we would probably still want motmod to invoke the
command "under the hood" instead of making the
average LinuxCNC user explicitly think about threads.
> 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.
I think that is only because of the way threads are
created today. In my mental model of HAL, pins
and parameters belong to components, just like pins
of integrated circuits on a PC board belong to the
parts that are soldered to the board.
On a PC board, signals (nets or traces in PC board
design terminology) are a different class of things.
They don't inherently belong to any of the parts on
the board, instead they belong to the board itself
and connect the parts. Likewise, HAL signals to
belong to HAL itself, not any of the loaded components.
I see threads as more like signals than pins. Threads
should exist as part of HAL itself, not belonging to any
one component, and they shouldn't stop and go away
until you shut down HAL.
> 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.
The intent is that threads are owned by HAL. Motmod
is inconsistent with that definition because the distinction
doesn't matter to most people who use motmod. The
goal, especially when HAL first came out, was to make
the transition from the old way to the HAL way transparent
to the average user.
> 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 wouldn't say "barely anybody" uses threads. It isn't
used by people who are running a finished LinuxCNC
configuration. But it is used by people who are doing
other things with HAL, and I'm pretty sure it is used
under the hood by the configuration wizards. For
example, stepconf lets you actually run an axis. I think
it uses threads to create the threads it needs to do that.
It could certainly use a "newthread" command instead,
if such a thing existed.
--
John Kasunich
jmkasun...@fastmail.fm
------------------------------------------------------------------------------
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
