Alvaro Lopez Ortega
Mon, 23 Jan 2006 07:19:42 -0800
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 Cherokee@lists.alobbs.com http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee