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 _______________________________________________ orbit-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/orbit-list
