Embedding Cherokee

Hi,

I consider using Cherokee as an embedded webserver for our
SOPE 
application server to avoid the necessity to install an
Apache module 
for running SOPE based applications.
In other words, I would like to directly link Cherokee into
the 
application, sometimes as a shared and sometimes as a static
library 
(is the latter supported or does Cherokee require that
modules are 
dynamically loaded?).

Is this a reasonable use of Cherokee, that is, will this
kind of use be 
"officially supported" in addition to standalone
operation?


For now I see two issues (somewhat connected) which I would
need to get 
resolved:
a) runloop integration
b) threading

a) NSRunLoop integration
We already have a select/poll based runloop (NSRunLoop)
which allows 
developers to register timers (NSTimers) and watch socket
IO. This is 
hard to impossible to change (at least on MacOSX), so my
idea would be 
to never run Cherokee in the main thread but always in a
subthread 
(which then possibly spawns additional subthreads for HTTP
request 
handling).
Viable approach?

b) threading
Another issue is that I would like to keep the processing of

application server requests serialized (single threaded, but
not 
necessarily triggered by the same thread). Probably I would
just place 
a global lock when Cherokee enters the appserver extension
for request 
processing.
What I wonder is whether such a lock might harm internal
operation of 
Cherokee in some way (IO timeout handling, cleanup
processes, etc) or 
whether there are any other things to be aware of?

Any suggestions are welcome 

Thanks a lot,
   Helge Hess

http://sope.opengroupw
are.org/
-- 
http://d
ocs.opengroupware.org/Members/helge/
OpenGroupware.org

_______________________________________________
Cherokee mailing list
Cherokeelists.alobbs.com
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee

Helge Hess wrote:

 > I consider using Cherokee as an embedded webserver for
our SOPE
 > application server to avoid the necessity to install
an Apache
 > module for running SOPE based applications.  In other
words, I would
 > like to directly link Cherokee into the application,
sometimes as a
 > shared and sometimes as a static library (is the
latter supported or
 > does Cherokee require that modules are dynamically
loaded?).
 >
 > Is this a reasonable use of Cherokee, that is, will
this kind of use be
 > "officially supported" in addition to
standalone operation?

   It hasn't been the most extended use of Cherokee, but we
have spent
   a considerable amount of time and work to make it
possible. So, I
   would say: Yes, it is.

 > For now I see two issues (somewhat connected) which I
would need to
 > get resolved: a) runloop integration b) threading
 >
 > a) NSRunLoop integration
 > We already have a select/poll based runloop
(NSRunLoop) which allows
 > developers to register timers (NSTimers) and watch
socket IO. This
 > is hard to impossible to change (at least on MacOSX),
so my idea
 > would be to never run Cherokee in the main thread but
always in a
 > subthread (which then possibly spawns additional
subthreads for HTTP
 > request handling).  Viable approach?

   Well, at first look, it might be possible with a
reasonable effort.
   Basically you will need to rewrite a couple of functions
in order to
   integrate it with your polling mechanism.

   Cherokee is using a polling class named fdpoll
(cherokee/fdpoll.h)
   which is a abstract class, so we could also try to write
a
   connector/bridge between NSRunLoop and fdpoll and let
things as they
   are at the moment.

 > b) threading
 > Another issue is that I would like to keep the
processing of
 > application server requests serialized (single
threaded, but not
 > necessarily triggered by the same thread). Probably I
would just
 > place a global lock when Cherokee enters the appserver
extension for
 > request processing.  What I wonder is whether such a
lock might harm
 > internal operation of Cherokee in some way (IO timeout
handling,
 > cleanup processes, etc) or whether there are any other
things to be
 > aware of?

   The number of threads in the server is fixed. Well,
actually there
   are two ways in which run the server: single thread (it
is not even
   linked with libpthread) and multi-thread. In this case it
is
   possible to choose the number of threads, but it is not
possible to
   change it over the time.

   I haven't seen the point on launching and killing threads
on the
   fly, but at some point if we think it is a good thing to
do, we
   might work on it as a new feature.

 > Any suggestions are welcome 

   Yep, here as well 

-- 
Greetings, alo.
_______________________________________________
Cherokee mailing list
Cherokeelists.alobbs.com
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee