Re: [Cppcms-users] feedback after testing cppcms svn trunk compiled with msvc2005

[Cristian O. <one...@gm...>]

On Thu, Jan 20, 2011 at 1:30 PM, Artyom <art...@ya...> wrote:
> First of all thanks for contributions
> they are very important!
>
>
>
>
>> Hi,
>>
>> I'm currently testing cppcms from svn trunk compiled with msvc2005  (I
>> know that the wiki states that only MSVC9 and MSVC10 are supported  but
>> MSVC8 works just as fine).
>> As a first impression I would like to say  that the lib looks really
>> good
>> I intend to use it in combination with  apache+mod_fastcgi.
>> After a few days of working with it I found the following  issues and I
>> want to share them with you:
>
> Basically I just had no chance to test in on MSVC8 so I published
> what I could test. If it works fine I'll add it to the
> supported platforms list (even thou it wouldn't be used in nightly builds and
> tests)
>
>> 1. The application does not  handle shutdown requests sent by
>> mod_fastcgi; a simple solution would be to  add the mechanism used in
>> libfcgi (the fastcgi client implementation provided  by
>> www.fastcgi.com) see  the attached
>> apache_mod_fastcgi_nice_shutdown.patch - nothe that the  implementation
>> could be improved to use a cppcms thread instead of  _beginthread.
>
> Ok this is good because I hadn't tested it with Apache on Windows.
>
> Few points:
>
> 1. Why and how does this work?
>
>   HANDLE shutdownEvent = (HANDLE) atoi(val);
>
>   Isn't handle has meaning inside process only? Or it
>   can be shared between processes this way?

AFAICT from looking at libfcgi and mod_fastcgi code mod_fastcfg places
the shutdown event handle in the client's environment in the
_FCGI_SHUTDOWN_EVENT_ variable. As I've said I've taken the code from
libfcgi\os_win32.c
(www.fastcgi.com/dist/fcgi-2.4.1-SNAP-0910052249.tar.gz), it works so
it means that is can be shared between parent and child processes.

> 2. I think there should be better handling of shutdown:
>
>   It should wait for multiple objects because process may
>   go down for other reason and the thread should be stopped
>   as well.
>
>   BTW: booster::thread can be used for this purpose.
>
>   it should be something like a special class
>   that stops its thread in destructor or something
>   like that.
>
>   I'll take a look on this.

Thanks, the better handling would be even "better" :).

>
>> 2. When trying the hello/form example I was getting an infinite  loop
>> in the application due to the fact that an input stream was  tested
>> only for eof and not for validity  see
>> http_request_infinite_loop.patch.
>
> Thanks, you are right, I'll commit it.
>
>> These two where critical issues that  I would like to see solved
>> somehow in cppcms. The following two patches are  just insignificant
>> improvements:
>> 3. Enable using external boost lib while  running cmake configure and
>> add an extra name for the zlib library on  Windows
>> cmake_permit_using_external_boost_and_zlib_on_win_name.patch
>
> Actually CppCMS no longer supports external boost and this
> is for ABI stability reason - I don't want users
> to have programs to fail because he uses boost_1_43 in their
> program and CppCMS was compiled against 1_44 or 1_36.
>
> The internal boost is not only subset of boost but rather
> renamed version of it (namespace boost -> namespace cppcms_boost)
>
> These ifdefs should go in any case.

It's good to know this. But boost is not a runtime dependency meaning
that after building cppcms if I use boost in the application linked
with cppcms I don't need to use the same version of boost, am I
correct?

>
>> 4.  This fixes the only code incompatibility I have found on  msvc2005
>> (mscv_2005_compatibility.patch) but googleing revealed that this  can
>> be fixed using a never winsdk so this is only important if  upgrading
>> is not an option
>> This is all for  now.
>>
>
> Thanks I'll commit this as well.

Thanks,
Cristian

>
>
> Thank you very much,
>   Artyom