Re: Fixing trunk build on OpenBSD

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.
Received on Wed Feb 15 2012 - 17:07:07 MST