Am 19.09.2012 um 21:22 schrieb John Kasunich: > > > 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.
John, your idea does not strike me as stupid at all. It just occurred to me that making the 'HAL session' something more explicit might help solve another problem as well. Think for a moment that usrmotif.* and friends are gone, and the interface between task and motion is based on messages. Being in the role of task: where do you send the message? if a HAL session/instance is not a singleton with only one possible destination, but possibly several HAL instances (call them 'spindle1' .. 'spindleN' to hint at a use case), then you need an address. Name it a HAL session identifier, or HAL instance address - same thing. It's a logical destination, and a name; it doesnt imply whether the instance is on a particular host, that would be a lower-level configuration detail. It also does not imply that we need to immediately reimplement HAL such that several HAL instances are possible on a single host; all it does is making such a setup possible by defining names to address targets. Note that 'motion instance X' isnt a particularly good address, because it special-cases motion to be the only possible recipient of messages. Making the HAL session identifier the target of command messages gets around this, and leaves out the detail of how command messages are handled within a HAL instance, which shouldnt be visible to the command originator in the first place. Clearly a HAL session which isnt fully established or configured does not make a good command message recipient, so there's an obvious correlation between 'established HAL session' and 'valid command recipient'. It really boils down to spelling out the basic operations of a HAL session to define it as an abstract data type: establish, name, teardown, accept command; on the using side 'send command to <instance name>' or the like. > 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. The example case (reporting HAL groups as compound messages of several HAL signals) is directed at a messaging model, though not request/reply; I would think publish/subscribe is the more suitable pattern for status reporting. I'm exploring a model where a 'HAL group name' becomes a 'topic name' on the publish/subscribe level automatically, and serialisation of HAL objects is derived from the group member list, with the idea of having status messages generated by HAL-only configuration and nothing else. I would think retrieving the names and types from HAL at startup or on change is good enough; pounding the HAL locks and object lists for every message would be a bit inefficient. For command input into a HAL instance, a request/reply type RPC would be the better fit at the macroscopic level, I think. I'm still fiddling the puzzle with respect to intra-HAL messaging to enable layering of components at the command level (such that one component provides a service, and another component can use it by sending a message; for instance a homing component sending a 'feed move' or 'probe' command and motion would execute it). - Michael > > -- > 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
