John, Am 19.09.2012 um 15:16 schrieb John Kasunich:
> 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 this fix is not particularly important for LinuxCNC2. So I do not see a pressing need to push this fix into the current code; I was more surprised to see it. However, let me explain how this fits in with LinuxCNC3 as I see it, and why it I think we need a better long-term solution to the concept of a HAL session resting implicitly on the number of loaded components. One part of the agenda is generalizing the current special-case motion/task interface. Task can send commands to motion, and retrieve status. Let us for the moment concentrate on the status reporting aspect. One way to define a status message - a compound of several scalar types - with the means of HAL is to define a group (which would be a new HAL object) which is an ordered set of signals, and some attributes at the group and member level. Both the group, and its member signals, are first class objects, i.e. exist without resting on a particular module. Once defined, pins of 'interesting modules', e.g. motion, can be linked to signals in such a group, and those pin values become fields in the group report. With such a compound object, it becomes straightforward to monitor the group for change, or just send a periodic status update of the group to a consuming entity, for instance task. Extra benefit: no more need to duplicate status values in emcstat, *and* in a HAL pin; and a scheme which is generally usable for any component, not just motion. While doing this - and the concept works out nicely so far - I stumbled across this bug, which is why I would like to see a longer term solution. I have no particular preference, but I would see halcmd operations and hal_lib.c equivalents to starting and ending a session as one way to go, which has the added benefit of making the concept of a 'HAL session' explicit - which was new to me, at least it's impact on memory management. - Michael > 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.) > > > 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 > -- > John Kasunich > [email protected] > > > ------------------------------------------------------------------------------ > 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
