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.
John - I'm warming up to the idea - having metadata in userland, eg redis, that is; I see some major benefits for introspective capabilities for using programs, besides the simplification of the shared memory segment management. Also, things like my HAL groups idea could be layered more easily ontop without impact on the core HAL code. Would you agree that the first step is the 'remotification of the halcmd interface'? (basically replacing the halcmd 'do_*()' methods by RPC's to the HAL server) for example: int do_newsig_cmd(char *name, char *type) (in halcmd_commands.c) would mutate into something like int do_newsig_cmd(hal_session_t *session, char *name, char *type) ---------------------------------^^^^^^^ this is the HAL session object we talked about and the HAL server would actually executed the current do_newsig_cmd() code this approach would be nearly API-compatible (except for the new session handle parameter, and new commands to establish, name and teardown a session) past that step, the HAL server + hal_lib.c code could be changed to 'userland metadata management' without an impact on the existing API, and hence completely independent of the using code there's another reason why the above makes sense: going back to a distributed model with one, or maybe several HAL instances on several cpu's would suggest such a remote interface anyway -- the tough question to which I dont have a good answer yet: how will kernel RT components access hal_* functions if they vanish from the common RTAPI/ULAPI code and migrate to userland completely? I've read through http://people.ee.ethz.ch/~arkeller/linux/multi/kernel_user_space_howto.html#toc7 but none of the options there strikes me as the obvious method. Any suggestions? - 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 ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
