[omniORB] Re: deactivate_impl() or other way to interrupt impl_is_ready()

[Sai-Lai Lo]

Hi Dietmar,

[omniorb-list: the subject is snapshot_980410]

I think having #define bool in some headers is problematic. The
-DNo_Cplusplus_Bool is only useful when it is known when building the
omniORB2 libraries that one has to operate in such an environment.
In the long run, it is best to remove any bool #define in all the code to 
avoid confusion. What we could do to help is perhaps to put a #ifdef bool in 
CORBA_sysdep.h and trap that as an error. This gives the developer a wake
up call on the potential conflict.

The stubs are already DLL ready. What I do in building omniORB DLLs is not
to use dllexport but to use a .def file. Have a look at
src/lib/omniORB2/sharedlib/dir.mk. At the end of it is a make rule to
produce a file omniORB.def which is the .def file for omniORB251_rt.dll. It
is completely automatic.

I suggest you do the same with a stub DLL. What you have to do in addition
is to #define Use_stub_in_nt_dll before the header file for each of the
stub in the DLL is included. This is important because this activates the
__decl(dllimport) on all typecode constants that are initialized in the
DLL. Have a look at the comments in CORBA_sysdep.h.

Yes, BOA::impl_shutdown() is the correct way to interrupt impl_is_ready().
I choose not to use deactivate_impl() because the BOA is so poorly defined
that every implementation is slightly different in important ways.
I think it is useful to make it explicit that the behaviour is ORB
dependent, hence a different function name. Like the BOA, ImplementationDef
is deprecated/removed from the latest spec.

I send this message to omniorb-list as well because it may be of general
interest.

Regards,

Sai-Lai


>>>>> Dietmar May writes:
>Hi Dr. Lo,

> I saw that you released the namespace patch. Thanks for early access to 
> the code. It worked fine for me, except for one issue - which I've dealt 
> with:

> The unresolved externals which I had notified you about earlier cropped 
> up again. I finally traced it to a difference in the mangled names, due 
> to bool definition differences between the default omniORB build 
> environment (which, under MSVC 5.0, uses bool as a native type) and my 
> STL implementation (which defined bool as int). So, everything compiled 
> fine, both the omniORB libraries, and my application using the omniORB 
> headers. Except that bool was different. I finally just removed the 
> #define in the STL header (using a conditional for MSVC 5.0).

> In effect, I think the -DNO_Cplusplus_Bool which you put in won't help 
> unless it is also defined in the make files for building omniORB. bool 
> HAS to be the same for the omniORB library, and for the application code.


> Two other issues: the first is not an immediate need, the second is. 
> (Update - I have found an answer to the second 'need', but not to some 
> related questions).

> 1) It would be helpful, and soon perhaps necessary, to create a DLL 
> containing the omniORB generated stub files. I am not familiar with 
> building shared libraries under Unix, and under Windows there are 
> probably as many ways of doing it as there are compilers, but at least 
> with MSVC 5, I believe the syntax is:

>   ret_type _declspec(dllexport) _cdecl function_name (parameter_list);
>     and
>   _declspec(dllexport) var_type varname;

> (The alternatives are command line linker options - not a chance! - and 
> DEF files - impossible to generate because of name mangling).

> Sun uses the following macros in the Java Native Interface (JNI) support 
> for JDK 1.1. It seems to be strictly there for the Windows platform, and 
> I think they've tried to target all of the major compilers:

>   JNIEXPORT ret_type JNICALL function (...);

> Presumably, JNICALL maps to _declspec(dllexport) _cdecl on MSVC, while 
> others which may need a leading export specifier  could also be addressed 
> via JNIEXPORT.

> This is not a *real* high priority - I will need to have this support 
> within the next two months - but if you already have work in progress, I 
> don't want to duplicate it as I did with namespace support.


> 2) More urgently, I need to interrupt the impl_is_ready() method, and as 
> I understand it, the correct portable CORBA way to do this is with 
> deactivate_impl(). Unfortunately, it appears that this method is as yet 
> unimplemented in omniORB. Update - it took me a little while to find out 
> how to programmatically interrupt the operation of an omniORB server 
> (which I have learned since starting this e-mail). Somehow, I overlooked 
> the section on BOA::impl_shutdown() and destroy() in the manual. Is there 
> a reason why deactivate_impl() doesn't simply call these two methods? It 
> would make the shutdown code a little more portable. Or is there some 
> planned use for deactive_impl(), or a CORBA reason why this would not be 
> appropriate?

> Another related question is the ImplementationDef_ptr that is required 
> for both impl_is_ready() and deactivate_impl() doesn't seem to have a 
> meaningful value. This is obviously an which is vendor-specific. Does 
> ImplementationDef have any meaning under omniORB? I am currently using a 
> simple typecast of a null pointer. I tried ImplementationDef::_nil() only 
> to get a compiler error, and found it was simply stubbed out right now. 
> Is there a better default which should be used?

> Thanks.

> Regards,
> Dietmar