On 02/15/2012 06:48 AM, Amos Jeffries wrote: >>> Okay, I have finally got my fingers into action again on that dependency >>> loop between libipc and libmgr. >>> >>> Here is the symbol table scan results: >>> >>> libipc depends on these types (the constructors/destructors): >>> Mgr::Request >>> Mgr::Inquirer >>> Mgr::Response >>> >>> Mgr::StoreToCommWriter::close also makes an appearance but seems to be >>> a loose link that appears only when scanning MGR for provided symbols >>> used by IPC. But disappears when scanning MGR for required symbols >>> needed by IPC. >>> >>> libmgr depends on: >>> Ipc::StoreMap >>> Ipc::SendMessage >>> Ipc::TypedMsgHdr >>> Ipc::ImportFdIntoComm >>> Ipc::Inquirer >>> Ipc::Forwarder >>> >>> The list of these is so long its clear that this is the "lower" level >>> library and libmgr should be depending on it. >>> >>> required by libipc: >>> U _ZN3Mgr7RequestC1ERKN3Ipc11TypedMsgHdrE >>> U >>> _ZN3Mgr8InquirerC1E8RefCountINS_6ActionEERKNS_7RequestERKSt6vectorIN3Ipc11StrandCoordESaIS9_EE >>> >>> >>> U _ZN3Mgr8ResponseC1Ej8RefCountINS_6ActionEE >>> U _ZN3Mgr8ResponseC1ERKN3Ipc11TypedMsgHdrE >>> U _ZNK3Mgr8Response4packERN3Ipc11TypedMsgHdrE >>> >>> >>> >>> So, yes Kinkie your patch was right for a first step. But scanning >>> through Makefile.am I find a LOT of similar reversed lists like that >>> testRock one which is the only thing failing at present. Kind of strange >>> why they do not also fail just about everywhere. Makes me nervous about >>> making that change alone.
>> FWIW, the solution is probably to split libipc and/or libmgr into two >> libraries so that the resulting low- and high-level libraries can be >> properly ordered when linked. Changing the linking order of current >> libmgr and libipc cannot create a proper order since the libraries are >> mutually dependent. > Because some simple objects are constructed in the wrong library? I dont > think so. because at least one of these two libraries both * provides code needed by the other library and * uses code provided by the other library You have already identified at least some of that offending code as "Mgr::Request,etc constructors/destructors" that are called in libipc. I suspect there is consensus that libipc should be limited to low-level IPC operations. We just have to agree on the best way to move the higher-level IPC stuff (such as type-specific parsing of IPC messages) elsewhere. > IMO there is no reason for libipc to be running those constructors. It > could be pulling the packet data out into a buffer and passing it to a > handler registered by libmgr. Same way UDP packet handling works through > comm_read handlers from the upper level ICP/HTCP/DNS/WCCP components. On > the sending side, the Mgr:: objects inherit from Ipc::TypedMsgHdr, so it > could (does already?) provide a virtual pack() function which they > implement to pack themselves into a buffer that Ipc::Send...() controls. I hope the parsing problem can be solved by introducing a libipc message_type_id:message_object_creator registry map that will be used to create the right objects which can correctly parse received [UDS] messages without exposing libipc to those parsing details. I do not recommend discarding transport-specific information by copying the received message "data" into a buffer before parsing begins, especially if you want to use the same registration mechanism for handling IPC messages on Windows. A message is more than a buffer and there should be no reason to hide the remaining message information from the parsing code (which can have platform/transport-specific components). Message packing should be already handled by the pack() API. Object creation is a little more difficult because, without an object, we cannot use virtual parsing methods. HTH, Alex. > I got very close to that with the Subscription attempt earlier. Just > went way too far on the handler split. > > Working like UDP will also make it very easy to do some magic foo under > the hood on Windows etc and actually use localhost UDP for the > transport, instead of raw Unix sockets on POSIX systems. > >> >> Platform-specific failures just obscure the fact that the current order >> is wrong and cannot be fixed without changing the libraries. I cannot >> object to changing the current order if it seems to help, but we should >> keep in mind that any perceived improvement is probably illusory.
