cppcms-users — Disussions of users of CppCMS

Re: [Cppcms-users] Mounting both synchronous and asynchronous applications

[Artyom <art...@ya...>]

> From: CN <cn...@gr...>

> Hello,
> 
> Imagine my site has both synchronous (for user login) and  asynchronous  
> (for interactive activities) pages. Is it a correct and  good practice to  
> mount both synchronous and asynchronous applications  like the following  
> code?
> 
> //code begin
> class login:public  cppcms::application{ .... }
> class interaction:public cppcms::application{  .... }
> 
> int main()
> {
> cppcms::service  s(argc,argv);
> 
> s.applications_pool().mount(cppcms::applications_factory<login>());
> 
> booster::intrusive_ptr<interaction>  i=new  interaction(s);
> s.applications_pool().mount(i);
> 
> s.run();
> }
> //code  end
> 


Yes and not, you should provide a mount point
that would distinguish between them:

See: 

- 
http://art-blog.no-ip.info/cppcms_ref_v0_99/classcppcms_1_1applications__pool.html

- http://art-blog.no-ip.info/cppcms_ref_v0_99/classcppcms_1_1mount__point.html


> Please also correct me if my following thoughts are wrong:
> 
> -  When a request arrives, cppcms::service.run() loops all mounted  
>   applications and pass that request to every mounted application. It is  the  

>   responsibility of every application to filter the interested  passed in  
>   request by applying dispatcher().assign().
> 

Not it would pass the request to the first application
that matches the mount point pattern. And it would not
it to only one such application.

Note it is multi-layered search:

If there is no specific patch assigned to dispatcher
it would return error 404 (unless you had redefined
application::main and do not use dispatcher

> - This  program can fire multiple instances of "login" class. Every login  
>   instance runs as a separate thread. Thus this program can concurrently  
>   process multiple incoming synchronous (login) requests.
> 

Yes and No.

A pool of synchronous applications is created.
At each request once instance is taken from the
applications pool and passed to thread pool for execution.

Once it completes it is recycled for reuse in the pool.

So multiple instances run synchronously concurrently.

> - This  program process asynchronous requests only one at a time because  
> only  one instance of class "interaction" is created.
> 

No, asynchronous application is executed in main event loop,
when new request is ready it is passed to the application, unlike
the case of synchronous application it can detach the http::context
object and "keep" it for further response (to provide long polling).
and then get more requests.

So basically asynchronous application can handle multiple
request and this is needed mostly for server side events
and long polling.

See examples/chat

> As such, asynchronous  
> applications are most likely the bottleneck of performance when the  load  
> is heavier.

If you do heavy processing there then yes, but you should not.
You are expected to do very lightweight operations there
if you have heavy processing either use synchronous application
and notify the asynchronous one passing it the results.

Or use the CppCMS's thread pool to handle heavy operations.

Don't forget that you can't access asynchronous app. directly
from other threads you rather need to use cppcms::service::post
to pass the handler to the main event loop for execution
to ensure thread safety.

Basically:

- When you need COMET/Server side events use asynchronous app,
- Otherwise use synchronous one.

Artyom


      

Re: [Cppcms-users] Does CppDB use native database driver or ODBC-like layerss?

[Artyom <art...@ya...>]

> From: CN <cn...@gr...>
> 
> Hi!
> 
> CppDB's connection pool feature attracts me.
> 
> "Support as many  RDBMSs as possible via cppdb-odbc bridge" is quoted  from
> 
> http://cppcms.sourceforge.net/sql/cppdb/intro.html
> 
> I heard  that ODBC is slow. For windowz, configuring ODBC is also hugely  
> painful.
> 
> Does CppDB directly uses DBMS native drivers or  indirectly?
> Take PostgreSQL as an example, does CppDB directly call libpq  functions or  
> indirectly call them through some ODBC layers? If CppDB  depends on ODBC,  
> does CppDB suffer from performance  issue?
> 

Yes CppDB provides, native drivers: 

See: http://cppcms.sourceforge.net/sql/cppdb/backendref.html

ODBC should be used only for RDBMSs that do not have native drivers.

CppDB supports following native drivers: MySQL, Sqlite3, PostgreSQL

Artyom


      

[Cppcms-users] Does CppDB use native database driver or ODBC-like layerss?

[CN <cn...@gr...>]

Hi!

CppDB's connection pool feature attracts me.

"Support as many RDBMSs as possible via cppdb-odbc bridge" is quoted from

http://cppcms.sourceforge.net/sql/cppdb/intro.html

I heard that ODBC is slow. For windowz, configuring ODBC is also hugely  
painful.

Does CppDB directly uses DBMS native drivers or indirectly?
Take PostgreSQL as an example, does CppDB directly call libpq functions or  
indirectly call them through some ODBC layers? If CppDB depends on ODBC,  
does CppDB suffer from performance issue?

Regards,
CN

[Cppcms-users] Mounting both synchronous and asynchronous applications

[CN <cn...@gr...>]

Hello,

Imagine my site has both synchronous (for user login) and asynchronous  
(for interactive activities) pages. Is it a correct and good practice to  
mount both synchronous and asynchronous applications like the following  
code?

//code begin
class login:public cppcms::application{ .... }
class interaction:public cppcms::application{ .... }

int main()
{
cppcms::service s(argc,argv);

s.applications_pool().mount(cppcms::applications_factory<login>());

booster::intrusive_ptr<interaction> i=new interaction(s);
s.applications_pool().mount(i);

s.run();
}
//code end

Please also correct me if my following thoughts are wrong:

- When a request arrives, cppcms::service.run() loops all mounted  
applications and pass that request to every mounted application. It is the  
responsibility of every application to filter the interested passed in  
request by applying dispatcher().assign().

- This program can fire multiple instances of "login" class. Every login  
instance runs as a separate thread. Thus this program can concurrently  
process multiple incoming synchronous (login) requests.

- This program process asynchronous requests only one at a time because  
only one instance of class "interaction" is created. As such, asynchronous  
applications are most likely the bottleneck of performance when the load  
is heavier.

Thank you in advance!
CN

Re: [Cppcms-users] init(content::base &) can't be used in derived class of cppcms::application

[kpeo <sla...@ya...>]

Thank you for so detailed information and fast answer!
I take last revision (1661) and all works fine!

Also, think too that using new init functions in cppcms::application be more clear and convenient way for future use.

30.01.2011, 18:20, "Artyom" <art...@ya...>:
> Hello,
>
> There were new virtual member functions where added
> to cppcms::application:
>
>   void init()
>   void clear();
>
> That are called upon URL Dispatching automatically.
>
> Because you have your own init(foo &) it overloads application::init and
> actually
> hides it.
>
>    Because:
>       struct foo {
>          void init();
>       }
>
>       struct bar : public foo {
>          void init( int y);
>       }
>
>    Then:
>
>       bar b;
>       b.init() -- illegal as it hidden by overloaded version
>       you need to add
>
>       struct bar : public foo {
>          void init( int y);
>          void init() { foo::init(); }
>       }
>
> So simplest thing you can do is to add to your app
>
>    void init() {} if you don't use it at all
>
> Or better
>
>    void init() { my_parent_class::init(); }
>
> So it would not be unhidden.
>
> All this for support of additional programming
> style when your application and context can be the same
> object which may be very convenient because it allows
> to access much more powerful tools from view.
>
> See exaples/message_board
>
> In the second thought..
>
> I can fix it so it would work with overloading.
>
> Take rev. 1659, it should work fine.
>
> Artyom
>
> ----- Original Message ----
>
>>  From: kpeo <sla...@ya...>;
>>  To: cpp...@li...
>>  Sent: Sun, January 30, 2011 4:41:20 PM
>>  Subject: [Cppcms-users] init(content::base &) can't be used in derived class of
>> cppcms::application
>>
>>  Hello Artyom and all!
>>
>>  As i understood correctly, function like  init(content::base &) can't be used
>> now in derived class of  cppcms::application since r1653 of
>> cppcms/url_dispatcher.h, where new   init() is now used.
>>
>>  So we should to rename our init(content::base &)  function to ini(content::x &)
>> for example, to avoid compile errors  like:
>>
>>  /usr/local/include/cppcms/url_dispatcher.h: In constructor
>> ‘cppcms::url_dispatcher::page_guard<C, typename
>> booster::enable_if<booster::is_base_of<cppcms::application, C>,
>> void>::type>::page_guard(C*) [with C =  app::project]’:
>>  /usr/local/include/cppcms/url_dispatcher.h:210:    instantiated from ‘void
>> cppcms::url_dispatcher::binder0<C>::operator()()  const [with C =
>> app::project]’
>>  /usr/local/include/booster/function.h:163:   instantiated  from ‘void
>> booster::function<Result()>::callable_impl<void,  F>::call() [with F =
>> cppcms::url_dispatcher::binder0<app::project>,  Result = void]’
>>  /media/opnp/project.cpp:161:   instantiated from  here
>>  /usr/local/include/cppcms/url_dispatcher.h:187: error: no matching  function
>> for call to ‘app::project::init()’
>>  /media/opnp/project.cpp:49: note:  candidates are: void
>> app::project::init(content::base&)
>>
>>  /media/opnp/project.cpp:161 - end  '}' of "namespace app {"
>>
>>  /media/opnp/project.cpp:49:
>>
>>  46:  project::project(site &s) :     base(s)
>>  47: {
>>  48: //
>>  49:  w.dispatcher().assign("^/?project/?(\\w+)?/?$",&project::out,this,1);
>>
>>  So,  i understand correctly and this is not a  bug?
>>
>>  ------------------------------------------------------------------------------
>>  Special  Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>>  Finally, a  world-class log management solution at an even better price-free!
>>  Download  using promo code Free_Logger_4_Dev2Dev. Offer expires
>>  February 28th, so  secure your free ArcSight Logger TODAY!
>>  http://p.sf.net/sfu/arcsight-sfd2d
>>  _______________________________________________
>>  Cppcms-users  mailing list
>>  Cpp...@li...
>>  https://lists.sourceforge.net/lists/listinfo/cppcms-users
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Cppcms-users mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppcms-users

Re: [Cppcms-users] init(content::base &) can't be used in derived class of cppcms::application

[Artyom <art...@ya...>]

Hello,

There were new virtual member functions where added
to cppcms::application:

  void init()
  void clear();

That are called upon URL Dispatching automatically.

Because you have your own init(foo &) it overloads application::init and 
actually
hides it.

   Because:
      struct foo {
         void init();
      }

      struct bar : public foo {
         void init( int y);
      }

   Then:

      bar b;
      b.init() -- illegal as it hidden by overloaded version
      you need to add 

      struct bar : public foo {
         void init( int y);
         void init() { foo::init(); }
      }

So simplest thing you can do is to add to your app

   void init() {} if you don't use it at all

Or better 

   void init() { my_parent_class::init(); }

So it would not be unhidden.

All this for support of additional programming
style when your application and context can be the same
object which may be very convenient because it allows
to access much more powerful tools from view.

See exaples/message_board


In the second thought..

I can fix it so it would work with overloading.

Take rev. 1659, it should work fine.

Artyom



----- Original Message ----
> From: kpeo <sla...@ya...>
> To: cpp...@li...
> Sent: Sun, January 30, 2011 4:41:20 PM
> Subject: [Cppcms-users] init(content::base &) can't be used in derived class of 
>cppcms::application
> 
> Hello Artyom and all!
> 
> As i understood correctly, function like  init(content::base &) can't be used 
>now in derived class of  cppcms::application since r1653 of 
>cppcms/url_dispatcher.h, where new   init() is now used. 
>
> So we should to rename our init(content::base &)  function to ini(content::x &) 
>for example, to avoid compile errors  like:
> 
> /usr/local/include/cppcms/url_dispatcher.h: In constructor  
>‘cppcms::url_dispatcher::page_guard<C, typename  
>booster::enable_if<booster::is_base_of<cppcms::application, C>,  
>void>::type>::page_guard(C*) [with C =  app::project]’:
> /usr/local/include/cppcms/url_dispatcher.h:210:    instantiated from ‘void 
>cppcms::url_dispatcher::binder0<C>::operator()()  const [with C =  
>app::project]’
> /usr/local/include/booster/function.h:163:   instantiated  from ‘void 
>booster::function<Result()>::callable_impl<void,  F>::call() [with F = 
>cppcms::url_dispatcher::binder0<app::project>,  Result = void]’
> /media/opnp/project.cpp:161:   instantiated from  here
> /usr/local/include/cppcms/url_dispatcher.h:187: error: no matching  function 
>for call to ‘app::project::init()’
> /media/opnp/project.cpp:49: note:  candidates are: void  
>app::project::init(content::base&)
> 
> /media/opnp/project.cpp:161 - end  '}' of "namespace app {"
> 
> /media/opnp/project.cpp:49:
> 
> 46:  project::project(site &s) :     base(s)
> 47: {
> 48: //
> 49:  w.dispatcher().assign("^/?project/?(\\w+)?/?$",&project::out,this,1);
> 
> So,  i understand correctly and this is not a  bug?
> 
> ------------------------------------------------------------------------------
> Special  Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a  world-class log management solution at an even better price-free!
> Download  using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so  secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Cppcms-users  mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppcms-users
> 


      

[Cppcms-users] init(content::base &) can't be used in derived class of cppcms::application

[kpeo <sla...@ya...>]

Hello Artyom and all!

As i understood correctly, function like init(content::base &) can't be used now in derived class of cppcms::application since r1653 of cppcms/url_dispatcher.h, where new  init() is now used. 
So we should to rename our init(content::base &) function to ini(content::x &) for example, to avoid compile errors like:

/usr/local/include/cppcms/url_dispatcher.h: In constructor ‘cppcms::url_dispatcher::page_guard<C, typename booster::enable_if<booster::is_base_of<cppcms::application, C>, void>::type>::page_guard(C*) [with C = app::project]’:
/usr/local/include/cppcms/url_dispatcher.h:210:   instantiated from ‘void cppcms::url_dispatcher::binder0<C>::operator()() const [with C = app::project]’
/usr/local/include/booster/function.h:163:   instantiated from ‘void booster::function<Result()>::callable_impl<void, F>::call() [with F = cppcms::url_dispatcher::binder0<app::project>, Result = void]’
/media/opnp/project.cpp:161:   instantiated from here
/usr/local/include/cppcms/url_dispatcher.h:187: error: no matching function for call to ‘app::project::init()’
/media/opnp/project.cpp:49: note: candidates are: void app::project::init(content::base&)

/media/opnp/project.cpp:161 - end '}' of "namespace app {"

/media/opnp/project.cpp:49:

46: project::project(site &s) :     base(s)
47: {
48: //
49: w.dispatcher().assign("^/?project/?(\\w+)?/?$",&project::out,this,1);

So, i understand correctly and this is not a bug?

Re: [Cppcms-users] service.list can't be used because cppcms::json::value::operator[] is used with a path instead of a name

[Artyom <art...@ya...>]

You, are right,

Thanks for the report, 
Fixed in trunk, changeset 1646.

Which reminds me that I need to add some unit-tests for multiple acceptors
configuration...

Artyom






----- Original Message ----
> From: Cristian Oneț <one...@gm...>
> To: cppcms-users <cpp...@li...>
> Sent: Mon, January 24, 2011 1:51:19 PM
> Subject: [Cppcms-users] service.list can't be used because 
>cppcms::json::value::operator[] is used with a path instead of a name
> 
> Hi,
> 
> I attached a patch to fix this. AFAICT this was the only place in  the
> code where cppcms::json::value::operator[] was called with a  path
> instead of a name.
> 
> Regards,
> Cristian
> 


      

[Cppcms-users] service.list can't be used because cppcms::json::value::operator[] is used with a path instead of a name

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

Hi,

I attached a patch to fix this. AFAICT this was the only place in the
code where cppcms::json::value::operator[] was called with a path
instead of a name.

Regards,
Cristian

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

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

On Fri, Jan 21, 2011 at 4:51 PM, Artyom <art...@ya...> wrote:
>
>
>> >  - Apache/win32 shutdown support added as well, pleas check this.
>>
>> Thanks, it  looks much better that way but it still needs a fix. After
>> the scope is left  the objects are destroyed thus causing a crash (see
>> the attached patch for  one possible solution).
>>
>
> I've committed the fix.
> Please update and check if it works.
>
> Note: you need to revert that "static" fix src/service.cpp in order to make
> sure that the fix I've committed works.

Thanks, your fix works the application is stopping as expected when
the server is stopping.

Regards,
Cristian

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

[Artyom <art...@ya...>]

> >  - Apache/win32 shutdown support added as well, pleas check this.
>
> Thanks, it  looks much better that way but it still needs a fix. After
> the scope is left  the objects are destroyed thus causing a crash (see
> the attached patch for  one possible solution).
>

I've committed the fix.
Please update and check if it works.

Note: you need to revert that "static" fix src/service.cpp in order to make
sure that the fix I've committed works.

Artyom



      

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

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

On Fri, Jan 21, 2011 at 1:39 PM, Artyom <art...@ya...> wrote:
>> About  the backtrace fix: I thought of that yesterday but when I tried
>> it I was  getting a crash (ESP not maintained correctly) but today when
>> I've tried it  again it works as expected so I must have messed up my
>> build yesterday - the  bottom line is that the backtrace code from
>> trunk works here also
>
> So I should revert the changeset in backtrace? (MSVC <= 1500)

No, the changeset is OK and working.

>>
>> >  - Apache/win32 shutdown support added as well, pleas check this.
>> Thanks, it  looks much better that way but it still needs a fix. After
>> the scope is left  the objects are destroyed thus causing a crash (see
>> the attached patch for  one possible solution).
>>
>
> I see. I know what is the problem I'll fix this.

Thanks,
Cristian

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

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

On Fri, Jan 21, 2011 at 1:38 PM, Artyom <art...@ya...> wrote:
>
>
>> From: Cristian Oneț <one...@gm...>
>>
>> I just find another small issue while trying to use  #include
>> <cppcms/json.h> in my application. In the "wonderful world" of  msvc
>> you can choose how wchar_t is interpreted by the compiler [1] so  if
>> "/Zc:wchar_t-" is used wchar_t is defined as "unsigned short" and  not
>> as a native type. In this case CPPCMS_JSON_SPECIALIZE_INT(wchar_t)  and
>> CPPCMS_JSON_SPECIALIZE_INT(unsigned short) will be one and the  same
>> and result in a compilation error which can be fixed by the  attached
>> patch.
>>
>> [1]  http://msdn.microsoft.com/en-us/library/dh8che7s%28v=vs.80%29.aspx
>>
>> Regards,
>> Cristian
>>
>
> C++ standard requires that wchar_t is distinct type, and defining it
> same type as unsigned short is not right and will not be supported.
>
> According to link, MSVC uses /Zc:wchar_t by default so it should
> be distinct type.
>
> If this is not default then it should be defined so in compilation
> options with this compiler.
>
> I'm not going to do ifdefs to support broken compiler especially
> if a simple flag can fix this and new versions of MSVC do this right.
>
> Artyom

Fair enough, I can live with that.

Regards,
Cristian

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

[Artyom <art...@ya...>]

> About  the backtrace fix: I thought of that yesterday but when I tried
> it I was  getting a crash (ESP not maintained correctly) but today when
> I've tried it  again it works as expected so I must have messed up my
> build yesterday - the  bottom line is that the backtrace code from
> trunk works here also

So I should revert the changeset in backtrace? (MSVC <= 1500)

> 
> >  - Apache/win32 shutdown support added as well, pleas check this.
> Thanks, it  looks much better that way but it still needs a fix. After
> the scope is left  the objects are destroyed thus causing a crash (see
> the attached patch for  one possible solution).
> 

I see. I know what is the problem I'll fix this.

Artyom



      

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

[Artyom <art...@ya...>]

> From: Cristian Oneț <one...@gm...>
> 
> I just find another small issue while trying to use  #include
> <cppcms/json.h> in my application. In the "wonderful world" of  msvc
> you can choose how wchar_t is interpreted by the compiler [1] so  if
> "/Zc:wchar_t-" is used wchar_t is defined as "unsigned short" and  not
> as a native type. In this case CPPCMS_JSON_SPECIALIZE_INT(wchar_t)  and
> CPPCMS_JSON_SPECIALIZE_INT(unsigned short) will be one and the  same
> and result in a compilation error which can be fixed by the  attached
> patch.
> 
> [1]  http://msdn.microsoft.com/en-us/library/dh8che7s%28v=vs.80%29.aspx
> 
> Regards,
> Cristian
>

C++ standard requires that wchar_t is distinct type, and defining it
same type as unsigned short is not right and will not be supported.

According to link, MSVC uses /Zc:wchar_t by default so it should
be distinct type.

If this is not default then it should be defined so in compilation
options with this compiler.

I'm not going to do ifdefs to support broken compiler especially
if a simple flag can fix this and new versions of MSVC do this right.

Artyom



      

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

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

Hi,

I just find another small issue while trying to use #include
<cppcms/json.h> in my application. In the "wonderful world" of msvc
you can choose how wchar_t is interpreted by the compiler [1] so if
"/Zc:wchar_t-" is used wchar_t is defined as "unsigned short" and not
as a native type. In this case CPPCMS_JSON_SPECIALIZE_INT(wchar_t) and
CPPCMS_JSON_SPECIALIZE_INT(unsigned short) will be one and the same
and result in a compilation error which can be fixed by the attached
patch.

[1] http://msdn.microsoft.com/en-us/library/dh8che7s%28v=vs.80%29.aspx

Regards,
Cristian

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

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

On Fri, Jan 21, 2011 at 8:15 AM, Artyom <art...@ya...> wrote:
> Hello,
>
> I've committed infinite loop and urandom patches.
> - the backtrace patch, no needed to do it the way you did
>  as I already has support of older SDK. Just changed ifdef
>  check if it works
About the backtrace fix: I thought of that yesterday but when I tried
it I was getting a crash (ESP not maintained correctly) but today when
I've tried it again it works as expected so I must have messed up my
build yesterday - the bottom line is that the backtrace code from
trunk works here also

> - Apache/win32 shutdown support added as well, pleas check this.
Thanks, it looks much better that way but it still needs a fix. After
the scope is left the objects are destroyed thus causing a crash (see
the attached patch for one possible solution).

> Artyom

Regards,
Cristian

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

[Artyom <art...@ya...>]

Hello,

I've committed infinite loop and urandom patches.
- the backtrace patch, no needed to do it the way you did
  as I already has support of older SDK. Just changed ifdef
  check if it works
- Apache/win32 shutdown support added as well, pleas check this.

Artyom




----- Original Message ----
> From: Cristian Oneț <one...@gm...>
> To: cpp...@li...
> Sent: Thu, January 20, 2011 12:37:32 PM
> Subject: [Cppcms-users] feedback after testing cppcms svn trunk compiled with 
>msvc2005
> 
> 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:
> 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.
> 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.
> 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
> 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.
> 
> Regards,
> Cristian Oneț
> 


      

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

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

On Thu, Jan 20, 2011 at 4:08 PM, Artyom <art...@ya...> wrote:
>>
>> Then I'm back to my original question: Can I use boost with  my
>> application if cppcms uses another version of boost internally?
>> From
>> what you have said "It is quite easy to show how programs  using
>> different versions of boost::regex in same code base crash." I  get
>> that *NO* I can't. But in the same time you say that cppcms should  not
>> be compiled against an external boost so how could I use  boost
>> together with cppcms in my  application?
>>
>
> Ok, now I understand what you ask.
>
> Of course you can!
>
> The internal boost is placed in "cppcms_boost" namespace so it would
> not collide with any other version of boost you use, this is
> the idea.
>
> Artyom

Great then :) sorry for the misunderstanding.

Regards,
Cristian

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

[Artyom <art...@ya...>]

> 
> Then I'm back to my original question: Can I use boost with  my
> application if cppcms uses another version of boost internally?
> From
> what you have said "It is quite easy to show how programs  using
> different versions of boost::regex in same code base crash." I  get
> that *NO* I can't. But in the same time you say that cppcms should  not
> be compiled against an external boost so how could I use  boost
> together with cppcms in my  application?
> 

Ok, now I understand what you ask.

Of course you can!

The internal boost is placed in "cppcms_boost" namespace so it would
not collide with any other version of boost you use, this is 
the idea.

Artyom


      

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

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

On Thu, Jan 20, 2011 at 3:38 PM, Artyom <art...@ya...> wrote:
>> Then this means that cppcms must be compiled  with the same version of
>> boost as the application.
>> Doesn't this imply usage  of an external
>> boost (the one that is shared with the application)? And you  just said
>> that using an external boost is not going to be supported anymore.
>
> No this means that CppCMS should not be compiled against Boost. Period.
>
> I'm quite surprised it worked for you at all because it shouldn't.
>
> Also I compile in some boost code so (iostreams) so you may get something
> very wrong as internal code may use different version.
>
> I think I'll remove this "EXTERNAL_BOOST" at all.
>
>
>> I'm
>> thinking of using the external boost feature only to compile  cppcms
>> and the application with the same version of boost (not the  opposite
>> that you are trying to avoid).
>
> CppCMS 1.x.x is going to handle stable ABI.
>
> So if you once compiled and application against version
> 1.0.0 then you can easily ugrade the dll for example to
> 1.8.3 and it should work out of the box same as for
> Qt4 or GTK2
>
> Boost does not support this, more then that it breaks
> ABI every 3 month...
>
>> Using an internal version of boost  is
>> what really opens the door for an application to use a  different
>> version of boost then the one cppcms uses.
>
> Yes exactly.
>
>> By the way which is  the
>> minimum version of boost which can be used to compile  cppcms?
>>
>
> I use internally 1.39 and slowly use it less and less in
> favor of booster - boost like library with some adopted/taken/redesigned
> boost API for ABI stability.
>
> Artyom

Then I'm back to my original question: Can I use boost with my
application if cppcms uses another version of boost internally? From
what you have said "It is quite easy to show how programs using
different versions of boost::regex in same code base crash." I get
that *NO* I can't. But in the same time you say that cppcms should not
be compiled against an external boost so how could I use boost
together with cppcms in my application?

Thanks,
Cristian

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

[Artyom <art...@ya...>]

> Then this means that cppcms must be compiled  with the same version of
> boost as the application.
> Doesn't this imply usage  of an external
> boost (the one that is shared with the application)? And you  just said
> that using an external boost is not going to be supported anymore.

No this means that CppCMS should not be compiled against Boost. Period.

I'm quite surprised it worked for you at all because it shouldn't.

Also I compile in some boost code so (iostreams) so you may get something
very wrong as internal code may use different version.

I think I'll remove this "EXTERNAL_BOOST" at all.


> I'm
> thinking of using the external boost feature only to compile  cppcms
> and the application with the same version of boost (not the  opposite
> that you are trying to avoid).

CppCMS 1.x.x is going to handle stable ABI.

So if you once compiled and application against version
1.0.0 then you can easily ugrade the dll for example to
1.8.3 and it should work out of the box same as for
Qt4 or GTK2

Boost does not support this, more then that it breaks
ABI every 3 month...

> Using an internal version of boost  is
> what really opens the door for an application to use a  different
> version of boost then the one cppcms uses.

Yes exactly.

> By the way which is  the
> minimum version of boost which can be used to compile  cppcms?
>

I use internally 1.39 and slowly use it less and less in 
favor of booster - boost like library with some adopted/taken/redesigned
boost API for ABI stability.

Artyom


      

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

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

On Thu, Jan 20, 2011 at 2:31 PM, Artyom <art...@ya...> wrote:
>> 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.
>>
>
> Ok, I'll take a look on this.
>
>> >
>> > 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?
>>
>
> Not correct.
>
> For example you use in cppcms
>
>  boost::foo() - from boost 1_36
>
> This symbol is defined in cppcms.lib (assuming it is statically linked)
>
> Now you are using boost_1_45 and you use boost::foo() as well and
> new boost::foo() is not binary compatible with 1_36
>
> Now linker may actually use the boost::foo from cppcms and not from the
> header you compiled with (and this actually happens).
>
> Now more then that if you use shared object under Unix it would
> happen with them as well. It is quite easy to show how programs
> using different versions of boost::regex in same code base
> crash.
>
> So no you can't - even if the symbols are inline symbols and the library
> is header only. Because compiler may create non-inlined weak symbols
> and share them at link stage (and this really happens) in order to reduce
> the size of the code.
>
> Read this for more details:
>
>
> http://stackoverflow.com/questions/836875/creating-library-with-backward-compatible-abi-that-uses-boost
>
>
> Regards,
>  Artyom

Then this means that cppcms must be compiled with the same version of
boost as the application. Doesn't this imply usage of an external
boost (the one that is shared with the application)? And you just said
that using an external boost is not going to be supported anymore. I'm
thinking of using the external boost feature only to compile cppcms
and the application with the same version of boost (not the opposite
that you are trying to avoid). Using an internal version of boost is
what really opens the door for an application to use a different
version of boost then the one cppcms uses. By the way which is the
minimum version of boost which can be used to compile cppcms?

Thanks,
Cristian

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

[Artyom <art...@ya...>]

> 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.
> 

Ok, I'll take a look on this.

> >
> > 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?
> 

Not correct.

For example you use in cppcms
 
 boost::foo() - from boost 1_36

This symbol is defined in cppcms.lib (assuming it is statically linked)

Now you are using boost_1_45 and you use boost::foo() as well and
new boost::foo() is not binary compatible with 1_36

Now linker may actually use the boost::foo from cppcms and not from the
header you compiled with (and this actually happens).

Now more then that if you use shared object under Unix it would 
happen with them as well. It is quite easy to show how programs
using different versions of boost::regex in same code base
crash.

So no you can't - even if the symbols are inline symbols and the library
is header only. Because compiler may create non-inlined weak symbols
and share them at link stage (and this really happens) in order to reduce
the size of the code.

Read this for more details: 

  
http://stackoverflow.com/questions/836875/creating-library-with-backward-compatible-abi-that-uses-boost


Regards,
  Artyom



      

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