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.) 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
