On 9/19/2012 9:16 AM, John Kasunich wrote: > I think this bug is actually a special case that doesn't > matter much for real systems. The fix seems dangerous, > but let me explain how I see it. > > I agree that signals aren't owned by any particular > component. But if no components at all are loaded, > then there is nothing for the signal to connect to. > > The issue here is deciding when a HAL "session" actually > ends. The current code assumes that if no components are > loaded, then the HAL session has ended and the shared > memory can be freed, so that the next time someone loads > a component a new session will be started with a fresh > (non-fragmented) HAL shared memory block. > > The proposed fix doesn't end the hal session unless > no components are loaded _and_ no signals exist. > During a normal linuxcnc shutdown, all components are > unloaded, but all signals are _not_ explicitly deleted. > > So fix would result in the HAL session never ending, > unless the hal script specifically deleted every signal > with a "delsig". Unless I've overlooked something, that > means the hal memory space would never get re-initialized > or de-fragmented until you reboot (or until you delsig > everything, but no existing configuration or run script > does that). > > hal_lib.c manages the memory used for HAL metadata > like pins and signals, and will re-use that memory > later without leaks. But the actual structures > declared by realtime components also come out of > the HAL memory space. Their sizes vary from > component to component, so it isn't very practical > to manage those blocks for re-use. In general > repeatedly loading and unloading components will > result in fragmenting the memory space and ultimately > running out of shared memory. > > No ordinary maching configuration has to worry > about fragmentation - every time you start up the > linuxcnc, it starts with a fresh memory space, loads > the components it needs, and then keeps that set > of components loaded until you shut down linuxcnc. > > During shutdown, when the last component is unloaded, > the memory space is freed, and the next time you start > linuxcnc it re-allocates the shared memory block. > > Gettign back to the original problem report: It is > certainly reasonable to create a signal before loading > any components and expect it to be there later. But it > is also reasonable to ask the user to wait until they > have loaded a component before they start making > signals. (And now that "net" is the most common way > of making signals, that is usually what happens.) I think the problem is that while John explains the rationale for the current behavior, Michael has described that signals are first class objects. That's a useful abstraction that is simple enough that most users can understand. Ideally, we need to define a new abstraction that is simple.
Failing that, the requirement for the user to load a component before creating any signals needs to be made explicit. The code should enforce that with a meaningful error message if one attempts to violate that requirement. Regards, Ken > > > On Wed, Sep 19, 2012, at 07:50 AM, Michael Haberler wrote: >> proposed fix: >> >> http://git.mah.priv.at/gitweb/emc2-dev.git/commitdiff/f3b037184e9e4e3a16dd764e1dd05e57d218d12d >> >> now the test.hal script 'properly fails' to link the signal of the wrong >> type, as the original signal definition remains intact: >> >> $ halcmd -f -k test.hal >> Signals: >> Type Value Name (linked to) >> s32 0 mysig >> >> test.hal:8: Signal 'mysig' of type 's32' cannot add pin 'passthrough.out' >> of type 'float' >> Signals: >> Type Value Name (linked to) >> s32 0 mysig >> >> -m >> >> Am 19.09.2012 um 10:16 schrieb Michael Haberler: >> >>> so far I thought HAL pins and params belong to components and go away when >>> the component exits whereas signals are first class objects which exist >>> independently of any component. (NB: hal_sig_t in src/hal/hal_priv.c has >>> NO owner_ptr member but params and pins DO have them.). >>> >>> If this is so, then the behaviour exhibited below is an error - signals >>> created by halcmd are deleted before a user component is loaded (internally >>> hal_exit() is called which deletes the signals which have erroneously been >>> 'associated' with the temporary component created by halcmd). >>> >>> I would think deleting signals by a hal_exit() is an error; however, this >>> is potentially a far-reaching change so I thought I better hear opinions >>> before fixing thos. >>> >>> - Michael >>> >>> ---- test.hal: >>> >>> newsig mysig s32 # note type >>> show sig mysig >>> >>> # this creates the passthrough.out *float* pin >>> loadusr -Wn passthrough python passthrough.py >>> >>> net mysig passthrough.out >>> #---^^^^^^^^^^^^^^^^^^^^^ so this should fail with a type error >>> # >>> # mysig magically mutated to a float: >>> show sig mysig >>> >>> -------- >>> >>> passthrough.py is the example from here: >>> http://www.linuxcnc.org/docs/devel/html/hal/halmodule.html >>> >>> $ halrun -v -V -f test.hal >>> HAL: initializing hal_lib >>> HAL: initializing component 'halcmd15311' >>> HAL: component 'halcmd15311' initialized, ID = 02 >>> HAL: creating signal 'mysig' >>> Signals: >>> Type Value Name (linked to) >>> s32 0 mysig >>> >>> HAL: removing component 02 <---------------- this >>> deletes the signals defined so far!! >>> HAL: component 02 removed, name = 'halcmd15311' >>> HAL: initializing hal_lib >>> HAL: initializing component 'halcmd15311' >>> HAL: component 'halcmd15311' initialized, ID = 04 >>> python passthrough.py >>> test.hal:6: Component 'passthrough' ready >>> test.hal:6: Program 'python' started >>> HAL: creating signal 'mysig' <---------------- signal mysig >>> implicitly created by net command >>> HAL: linking pin 'passthrough.out' to 'mysig' >>> test.hal:8: Pin 'passthrough.out' linked to signal 'mysig' >>> Signals: >>> Type Value Name (linked to) >>> float 0 mysig >>> <== passthrough.out >>> >>> HAL: removing component 04 >>> HAL: component 04 removed, name = 'halcmd15311' >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Emc-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/emc-developers >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
