[Catalyst] [OT] building perl with threads

2006-09-30 Thread Daniel McBrearty
now I have the hang of building apache/perl from source ...

what's the rationale behind the perl is normally built with thread
support OFF in a production environment?

is that what is recommended for cat under mod_perl / fastcgi?

-- 
Daniel McBrearty
email : danielmcbrearty at gmail.com
www.engoi.com : the multi - language vocab trainer
BTW : 0873928131

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] [OT] building perl with threads

2006-09-30 Thread Tobias Kremer
Daniel McBrearty schrieb:
  now I have the hang of building apache/perl from source ...
 
  what's the rationale behind the perl is normally built with thread
  support OFF in a production environment?
 
  is that what is recommended for cat under mod_perl / fastcgi?

AFAIK, if you don't really need threads you should not enable them
because this could have an impact on the overall performance of your
webapp.

So to answer your questions: Yes, it's recommended to compile perl
without any kind of thread-support for best Catalyst performance.

--Toby

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] [OT] building perl with threads

2006-09-30 Thread Daniel McBrearty
thanks Toby.

On 9/30/06, Tobias Kremer [EMAIL PROTECTED] wrote:
 Daniel McBrearty schrieb:
   now I have the hang of building apache/perl from source ...
  
   what's the rationale behind the perl is normally built with thread
   support OFF in a production environment?
  
   is that what is recommended for cat under mod_perl / fastcgi?

 AFAIK, if you don't really need threads you should not enable them
 because this could have an impact on the overall performance of your
 webapp.

 So to answer your questions: Yes, it's recommended to compile perl
 without any kind of thread-support for best Catalyst performance.

 --Toby

 ___
 List: Catalyst@lists.rawmode.org
 Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
 Dev site: http://dev.catalyst.perl.org/



-- 
Daniel McBrearty
email : danielmcbrearty at gmail.com
www.engoi.com : the multi - language vocab trainer
BTW : 0873928131

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] catalyst++

2006-09-30 Thread Matt S Trout
Garrett Goebel wrote:
 On Sep 29, 2006, at 11:22 AM, John Napiorkowski wrote:
 
 I'm not sure what you mean by 'multi-attribute
 dispatch routing'.  I have someone here working on
 integrating Class::Workflow as a controller so you can
 dispatch based on workflow states and not just on
 actions.  Is that something that interests you?
 
 I'm talking about the difference between single and multiple  
 dispatch. Catalyst's action attributes whether they're local, path,  
 regex, chained, etc. all are specific to the request uri. The  
 dispatcher tries each dispatch type until if finds one that matches  
 the path.
 
 I've modified the dispatcher so I can dispatch an action if it  
 matches request method and uri path. Dispatching based on workflow  
 states would be a nice addition. I've looked at Class::Workflow, but  
 never got past just looking at it. Yes, it does interest me.
 
 However, what I've done is a hack to meet my needs. It'd be nice if  
 there were a generic catalyst dispatcher which handled multiple  
 dispatch.

There already is. It's called Catalyst::Dispatcher.

We had a long thread about this where you kept saying but it can't do X and 
I followed up saying yes it can, you do it like this.

In the end your objections seemed to boil down to I don't like :ActionClass, 
at which point I pointed you in the direction to encapsulate that away in a 
controller base class.

I can't think of any point you raised that wasn't addressed as being viable 
against the standard dispatcher; if there are still things you believe can't 
be achieved please post *specific* examples rather than just complaining in 
general that it won't do what you want :)

-- 
  Matt S Trout   Offering custom development, consultancy and support
   Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/