On Wednesday 19 September 2012 20:44:30 Kenneth Lerman did opine: > 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 > Ken & company; Perhaps I don't have a good grasp of the problem, but somehow, my guess is that the realtime may be playing with it, but that the first character from the ser ports hardware buffer, should probably be fetched not with a string function, but with getchar itself, parsed and if its the o you are looking for, then initiate the box open, and transfer the focus, then get the rest of the hardware buffers contents which should still be waiting. IOW, the sequencing of the scan may not be correct. That would however, stress the 16 char buffer in the usual 16550 tty port when long filenames are involved.
Perhaps the reader code that reads the tty port could feed a 256 byte circular buffer, which could save a considerable amount of output from the scanner, and your code could read from this circular buffer? The buffer is filled from an irq from the tty, but your code wouldn't be driven from that, but from the buffers Data_AVailable (DAV) signal? At reasonable data rates, that should never drop a character. > > On Wed, Sep 19, 2012, at 07:50 AM, Michael Haberler wrote: > >> proposed fix: > >> > >> http://git.mah.priv.at/gitweb/emc2-dev.git/commitdiff/f3b037184e9e4e3 > >> a16dd764e1dd05e57d218d12d > >> > >> 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 Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! Once a woman has given you her heart you can never get rid of the rest of her. -- Vanbrugh ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
