Re: [PATCH] New function to deduce ORB capability

[KC <kcc1967 gmail com>]

Hi Jules,

>
> Everything would be much more simple if any client could use the
> "ORBInitialMsgLimit" orb option to disable the limit check or set the
> limit as high as possible but, due to an unfortunate design limitation
> in ORBit2, that is not possible.
>
> The, IMHO, design mistake is that all subsequent invocations of
> ORB_init() will return a copy of the first ORB to be initialized. This
> has the unfortunate effect that the first thread to invoke ORB_init()
> will set the capabilities of all subsequent ORBs to be "created" by any
> subsequent thread.

I agree with you this is a design mistake (I didn't know this before).
I think its better that subsequent ORB should be initialized by
hard-coded default options instead of inherit its default options
from previous ORB.

Should this be documented into the "known issue" ?


> It would be rather simple to export a function that disables the imposed
> recv limit, but that function would then change the capabilities of the
> ORB as set by the first thread. Any such change would be invisible to
> the first thread. I really do not believe in doing that. Changing the
> behavior of an ORB while another thread assumes certain
> limits/properties of the ORB is not acceptable IMHO.

Agree, the behavior of ORB should be determined at the
time of ORB_init() ... and better not be changed after initialized.

Regards
KC