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. -- 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
