Am 19.09.2012 um 23:28 schrieb John Kasunich: > > > On Wed, Sep 19, 2012, at 04:46 PM, EBo wrote: >> On Wed, 19 Sep 2012 15:22:19 -0400, John Kasunich wrote: >>> >>> 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. >> >> Well, it might pay to have both a HAL server and multiple >> threads/process within such a server which would require various types >> of locks or mutex's, but I can see how to set something like that up. > > Yes, at some point it becomes neccessary to deal with > requests from multiple concurrent "halcmds", whether it > is at the low level while the commands are being processed > (by parallel server threads), or at a higher level where > the server only processes one command at a time. > > This crazy server idea directly addresses one other thing > that has bothered me about the HAL implementation. The > only things that really needs to be in shared memory are > the actual signal values (8 bytes per signal) and the > pin pointers (which point to the signal that the pin is > connected to). > > The rest of the metadata, such as pin name, type, etc, > is only in shared memory so that things like halcmd, > halmeter, halscope, and others can access it. If we had > a HAL server, the metadata would reside in ordinary user > space memory as part of the server process memory space.
I see the elegance in the idea; it would be much easier to use stock parts like a STL map or a Python dictionary if this all were user land; coding with pointer offsets is a rough It looks straightforward for user comps; I'm a bit unsure how to do this for RTAI RT components - would they 'upcall an RPC'? I've played with several routes of doing user/kernel interactions from RTAI and I found the RTAI thread environment very limited to do such things without jumping extra hoops. I mean it's doable, for instance posting a rt service request from the RTAI thread to be executed once the normal kernel environment resumes, and then for instance use a netlink socket to do the RPC stunt from kernel to userland an back, or sysfs or some other vehicle, but it's not going to be pretty and stable at day one. I think the best we can do for now is - keeping the "one front at a time" principle in sight - is to design the messaging interface between the HAL instance and the rest of LinuxCNC such it doesnt depend on how those operations are actually executed -m > > -- > 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
