Re: [porting-cvs] CVS update [cws_src680_sb71]: /porting/sal/inc/sal/main.h

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [porting-cvs] CVS update [cws_src680_sb71]: /porting/sal/inc/sal/main.h

stephan.bergmann
Folks,

On CWS sb71 it turned out we need to move code on Windows from sal
DllMain to global main.  Hennes just did that and added two symbols to
the sal API (sal_initialize, sal_deinitialize).

My question is:  Should it be mandatory for any application using sal
(i.e., any native application based on URE) to use
SAL_IMPLEMENT_MAIN[_WITH_ARGS] from sal/main.h, or do we want to also
allow such an application to have its own explicit implementation of
main (which would then have to call sal_[de]initialize explicitly)?  (I
tend towards the former.)

If the former, we could and should make sal_[de]initialize "URE private"
symbols (that are publicly exported from sal, but not intended to be
explicitly called from client code), move them in
sal/util/sal.map:1.58.12.3 from section UDK_3.7 to section PRIVATE_1.1,
and probably rename them to sal_detail_[de]initialize (to match the
naming convention of the symbols already present in section PRIVATE_1.0).

Opinions anyone?
-Stephan

[hidden email] wrote:

> Tag: cws_src680_sb71
> User: hro    
> Date: 2007-08-22 14:38:30+0000
> Modified:
>    porting/sal/inc/sal/main.h
>
> Log:
>  #i77184# sal_initzialize and sal_deinitialize needed for Winsock initialization
>
> File Changes:
>
> Directory: /porting/sal/inc/sal/
> ================================
>
> File [changed]: main.h
> Url: http://porting.openoffice.org/source/browse/porting/sal/inc/sal/main.h?r1=1.7&r2=1.7.68.1
> Delta lines:  +24 -5
> --------------------
> --- main.h 2006-12-01 17:24:31+0000 1.7
> +++ main.h 2007-08-22 14:38:28+0000 1.7.68.1
> @@ -4,9 +4,9 @@
>   *
>   *  $RCSfile: main.h,v $
>   *
> - *  $Revision: 1.7 $
> + *  $Revision: 1.7.68.1 $
>   *
> - *  last change: $Author: rt $ $Date: 2006/12/01 17:24:31 $
> + *  last change: $Author: hro $ $Date: 2007/08/22 14:38:28 $
>   *
>   *  The Contents of this file are made available subject to
>   *  the terms of GNU Lesser General Public License Version 2.1.
> @@ -44,21 +44,40 @@
>  extern "C" {
>  #endif
>  
> +/*
> +Maybe these one should be documented for those who don't wat to use the
> +SAL_IMPLEMENT_MAINxxx macros.
> +
> +*HRO* Subject to change
> +*/
> +
> +void SAL_CALL sal_initialize();
> +void SAL_CALL sal_deinitialize();
> +
> +
>  /* Prototype needed below */
>  void SAL_CALL osl_setCommandArgs(int argc, char ** argv);
>  
>  #define SAL_MAIN_WITH_ARGS_IMPL \
>  int SAL_CALL main(int argc, char ** argv) \
>  { \
> + int ret; \
> + sal_initialize(); \
>   osl_setCommandArgs(argc, argv); \
> - return sal_main_with_args(argc, argv); \
> + ret = sal_main_with_args(argc, argv); \
> + sal_deinitialize(); \
> + return ret; \
>  }
>  
>  #define SAL_MAIN_IMPL \
>  int SAL_CALL main(int argc, char ** argv) \
>  { \
> + int ret; \
> + sal_initialize(); \
>   osl_setCommandArgs(argc, argv); \
> - return sal_main(); \
> + ret = sal_main(); \
> + sal_deinitialize(); \
> + return ret; \
>  }

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [porting-cvs] CVS update [cws_src680_sb71]: /porting/sal/inc/sal/main.h

Matthias Huetsch
Hi Stephan,

Stephan Bergmann wrote:
> Folks,
>
> On CWS sb71 it turned out we need to move code on Windows from sal
> DllMain to global main.  Hennes just did that and added two symbols to
> the sal API (sal_initialize, sal_deinitialize).

As a side note: Though I do understand why these changes are necessary,
may I still regard them as "ugly" (IMHO, of course)?

>
> My question is:  Should it be mandatory for any application using sal
> (i.e., any native application based on URE) to use
> SAL_IMPLEMENT_MAIN[_WITH_ARGS] from sal/main.h, or do we want to also
> allow such an application to have its own explicit implementation of
> main (which would then have to call sal_[de]initialize explicitly)?  (I
> tend towards the former.)

Simply: yes (i.e. the former).

>
> If the former, we could and should make sal_[de]initialize "URE private"
> symbols (that are publicly exported from sal, but not intended to be
> explicitly called from client code), move them in
> sal/util/sal.map:1.58.12.3 from section UDK_3.7 to section PRIVATE_1.1,
> and probably rename them to sal_detail_[de]initialize (to match the
> naming convention of the symbols already present in section PRIVATE_1.0).

With a "yes" to the first question, this is also "Yes", please make them
private.

Just my 2 cents,
Matthias

>
> Opinions anyone?
> -Stephan
>
> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [porting-cvs] CVS update [cws_src680_sb71]: /porting/sal/inc/sal/main.h

stephan.bergmann
Matthias Huetsch wrote:

> Hi Stephan,
>
> Stephan Bergmann wrote:
>> Folks,
>>
>> On CWS sb71 it turned out we need to move code on Windows from sal
>> DllMain to global main.  Hennes just did that and added two symbols to
>> the sal API (sal_initialize, sal_deinitialize).
>
> As a side note: Though I do understand why these changes are necessary,
> may I still regard them as "ugly" (IMHO, of course)?

Dead ugly I consider them, too, but probably for another reason than you
do:  They are an incompatible change.  (A Windows executable compiled
against old sal and run against new sal will neither execute sal's
initialization code in sal's DllMain---it has been removed from
there---nor execute sal_initialize---that call is inline in main.h, so
old code does not get it.  There hopefully are ca. zero Windows
executables built on URE out there in the wild, so we hopefully get away
with this.)

In hindsight, when the need to call *some* initialization
(osl_setCommandArgs) from main got catered for in sal/inc/sal/main.h:1.4
it would have been better to once-and-for-all cater for *any future*
initialization needs, by introducing sal_initialize right from the
start, and calling osl_setCommandArgs from within sal_initialize.  (And
we cannot now move the call to osl_setCommandArgs from main to
sal_initialze, for those compatibility reasons.)

A further thought:  Do we need sal_deinitialize (only called when
sal_main[with_args] returns normally) or would it be better to execute
any necessary deinitialization through atexit (thus also called when
calling exit)?  I would tend to think we should use atexit instead of
sal_deinitialize, but the above paragraph suggests that we probably
should be non-conservative in adding hooks into main.h?  Again, opinions
anyone?

[...]

>> If the former, we could and should make sal_[de]initialize "URE private"
>> symbols (that are publicly exported from sal, but not intended to be
>> explicitly called from client code), move them in
>> sal/util/sal.map:1.58.12.3 from section UDK_3.7 to section PRIVATE_1.1,
>> and probably rename them to sal_detail_[de]initialize (to match the
>> naming convention of the symbols already present in section PRIVATE_1.0).
>
> With a "yes" to the first question, this is also "Yes", please make them
> private.

Yes, will do.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: [porting-cvs] CVS update [cws_src680_sb71]: /porting/sal/inc/sal/main.h

stephan.bergmann
In reply to this post by stephan.bergmann
Stephan Bergmann wrote:
> In hindsight, when the need to call *some* initialization
> (osl_setCommandArgs) from main got catered for in sal/inc/sal/main.h:1.4
> it would have been better to once-and-for-all cater for *any future*
> initialization needs, by introducing sal_initialize right from the
> start, and calling osl_setCommandArgs from within sal_initialize.  (And
> we cannot now move the call to osl_setCommandArgs from main to
> sal_initialze, for those compatibility reasons.)

The last sentence is nonsense; we can do that move.  At least some
beauty regained.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]