On 15/02/2012 4:53 a.m., Alex Rousskov wrote:
On 02/13/2012 11:31 PM, Amos Jeffries wrote:
On 23/01/2012 1:44 a.m., Amos Jeffries wrote:
On 22/01/2012 11:24 p.m., Kinkie wrote:
On Sun, Jan 22, 2012 at 4:01 AM, Amos Jeffries<squ...@treenet.co.nz>
wrote:
On 22/01/2012 12:12 p.m., Henrik Nordström wrote:
lör 2012-01-21 klockan 22:27 +0100 skrev Kinkie:
Hi all,
the patch below seems to fix the build on OpenBSD. Does it make
sense?
What is the error?
But yes makes sense.. mgr depends on ipc I think.
Yes it does. And libipc depends on libmgr right back.
libmgr defines Mgr Request/Reply types with methods that use IPC,
and libipc
defines the Coordinator functions that create and use the
MgrRequest/Reply
types. I was arguing this out with Alex a while back but never got the
detailed function level analysis done.
Which library gets detected as broken depends on which source files
have
been touched recently.
So I understand that there really is no simple way now to fix things?
Maybe slicing off libmgr the Coordinator functions?
I'm sure there is. I just did not finish the analysis that was needed
to find it.
Amos
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.
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 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.
Amos
