On Fri, 9 Jan 2004, Kean Johnston wrote: > Good morning all, > > For a (private) project I am working on, I would appreciate a little > advice. The system produces mostly dynamic content, very little static > stuff. A lot of the data that will be served up by httpd comes from a > daemon running on the same host, and all of the required data is in a > shared memory segment.
SHared memory is not easy with Apache. If you implement a pool / pointers in shared memory, then you're significantly advancing it. If you need shared memory pointers, you might be better-off writing a separate daemon, and connecting to your module. > I can either produce the content with a CGI that attaches to the shared > segment, gets the data and renders it in HTML, I'd suggest a persistent daemon. Perhaps prototype it as a single program, then separate off the shm via RPC. Of course if your shm use doesn't involve pointers then it's all much simpler. > frequently and almost always in core. Of course, I can hack the web > server to my hearts content, and possibly even have the main httpd > create the semaphores and shared memory segments, so that when it > preforks, all of the children already have all of those set up and > simply need to use the semaphore for the read lock, render the data from > the shared segment and be done with it. Take a look at the DB Pool modules at apache.webthing.com. A similar approach might be what you need. > Do you think it would be overkill to write this as a module, or would > the simplicity gained by writing a normal CGI be worth it? I've not > written an Apache module before, so it would be a bit of a learning > curve, but a worthwhile one I think. I agree with that. Once you're up the curve it becomes just as simple as CGI, and gives you more flexibility and modularity. > I intend to implement this using httpd 2.0, if that makes any difference. Yes, that's a far more powerful development platform than 1.x. -- Nick Kew
