On 8/26/2012 1:11 AM, Michael Haberler wrote: > Am 26.08.2012 um 06:32 schrieb Michael Haberler: > >> Am 26.08.2012 um 01:11 schrieb Chris Morley: >> >>> >>>> 3. ALL guis, not just Axis, need to eventually learn how to start a >>>> POSTGUI_HALFILE if there is any chance itself or a subprocess creates >>>> additional HAL objects. To do so, they need to understand that they are >>>> the primary UI component. This suggests a per-ui command line flag like >>>> '--primary-ui'. >>> >>> AXIS, TOUCHY and The future Gscreen all understand POST_GUI. >>> TOUCHY requires a touchy.hal file though. >>> It would be nice if linuxcncTK could be retrofitted with POSTGUI and at >>> least PYVCP panels. >>> but TCL is not my bag.... >> I think by now the whole POSTGUI_HALFILE thing was a kludge. The linuxcnc.in >> assumption is: shutdown happens when the UI program exits, so just block on >> the UI program, and run cleanup thereafter. >> >> It would be much easier and uniform if: >> 1. linuxcnc.in just starts the UI in the background and records its pid >> 2. linuxcnc.in waits for the UI to be fully set up (all HAL comps/pins >> created and ready) >> 3. linuxcnc.in runs any POSTGUI type jobs. >> 4. when done, it explicitly waits for the UI pid. >> >> 1,3,4: easy >> 2: I'm taking suggestions - one cant tell in advance which halcomps are set >> up behind the UI, so you cant test for them being ready easily; also halcmd >> is less than helpful wrt exit status: say 'halcmd show comp axis' always >> reports exit status 0 even if comp axis doesnt exist. >> >> Maybe somebody has a simple idea in his bag of shell tricks how a process >> can notify the parent shell that some step is complete. > Well, stackoverflow.com came to the rescue, see > http://serverfault.com/questions/37796/how-to-export-vars-from-a-subshell-to-a-parent-shell/373307#373307 > > this could work as follows: > > - linuxcnc.in exports a, say "NOTIFY" environment variable which the UI can > access with getenv("NOTIFY"). Contents are irrelevant. > - linuxcnc.in starts the UI in the background and records its pid. > - if the UI sees the NOTIFY env variable, it shall: > -- create a fifo in the current directory with 'mknod notifiy.${pid} p' in > the current directory > -- when done with HAL setup, run a subshell like so 'echo DONE' > > notfiy.${pid} &' which wont block, or 'FAIL' or something if it failed to > start properly. > - linuxcnc.in tests for a while if notifiy.${pid-of-UI} appears in the > current directory. > - if doesnt after say 5 seconds, and the UI process still runs, this means > the UI doesnt support this notification convention, so say so and continue. > - if the UI process vanished, say so and shut down. > - if the pipe appeared, read it with: RESULT=`cat notifiy.${pid-of-UI}` > -- if RESULT=='DONE', go ahead and run any POSTGUI type jobs. > -- if RESULT== 'FAIL', say so and shutdown. > -- reading will make the 'echo DONE > notfiy.${pid} &' process (started by > the UI) terminate > -- the fifo can be unlinked after reading. > > this needs a bit of modification to each UI, but it's simple and the per-UI > POSTGUI handling code can head for deprecation. I think it's more general, > too; a UI being healthy and ready is more interesting as status report than > teaching it some POSTGUI_HALFILE execution trick. > > for regularity, really there should be a section [POSTGUI_HAL] which works > exactly like the HAL section, just run after the UI is ready. > > this is a change which will affect documentation and ini files. Opinions? > > - Michael >
That's a clever way to pass a message. I would think the big questions for many would be 1) does this break existing configurations? (Maybe not, but it's too late at night for me to be sure) and if so 2) can we automate the configuration-upgrade process to easy people's pain/anxiety about changing something that is working for them. Regards, Kent ------------------------------------------------------------------------------ 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
