On Wed, Sep 19, 2012, at 10:52 AM, Michael Haberler wrote: > 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.
I think the bug is obscure enough that we can ignore it in LCNC2. As Ken pointed out, it would be nice to have a meaningful error message. > 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. I agree 100%. Right now the session ends when you unload the last component. If probably makes more sense to have a command that explicitly shuts down HAL. Of course fixing people's configs would need to be part of the upgrade, otherwise we will have mysterious and hard-to- duplicate problems that occur only when someone runs LCNC3 fifty times without rebooting. > 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. I agree that this is the way to go. There is actually quite a lot of setup and shutdown stuff that is related to RTAI, that also leads to the idea of a "session". Take a look at dmesg after running LCNC2, and you will see a whole pile of messages from parts of RTAI during init, and a smaller set of messages as things shut down. Currently the run script does a lot of that. An idea just occurred to me, might be good, might be stupid: What if we had a user space program whose sole purpose in life is to be a HAL session? Maybe call it hald, since it would be a daemon of sorts. You invoke it, and it sets up the realtime stuff, allocates shared memory, and inits everything. You now have a HAL session, and can create signals, etc. When you kill the daemon process, it would do all the cleanup. Unload components, delete signals, free memory, shut down RTAI, etc. Taking this crazy idea one step farther, what if this daemon process was more of a "HAL server"? Instead of every instance of halcmd directly accessing the lists and other metadata, halcmd would simply ask the server to do it. I don't know much about how client-server stuff is implemented (RPCs?, sockets?) but if only the server is accessing the metadata, then the HAL mutex isn't needed, and the internals of HAL might not need to be visible to so many individual programs. -- 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
