Stay away from FastCGI++ if you can
So I'm in my praxis semester at the moment, and I have to work with fastcgi++, a C++ library for fastcgi. And it is a nightmare! Here comes why...
So first, the codebase of fastcgi++ is a mess. Code snippets like
bool foo = someFunction();
if (foo) return true;
else return false;
are everywhere. You really don't want to read that kind of code. And yes, you have to actually read this code because there is no documentation on how to use the library! There is a wonderful doxygen-generated API documentation, but that does not help you because, yeah, you know the types and the interfaces now – lucky you! How to build a fastcgi module with them – figure it out by reading through the codebase!
Secondly, you are not allowed to define your custom accept() handler. You
have to inherit from a Request class template and you have to implement the
virtual bool response(void) = 0; method. Okay, no problem, I can do this!
But then, you want to start accepting requests. You do this by creating an
instance of a class called Manager:
Fastcgipp::Manager<MyRequestInheritedClass> man();
man.handler();
or something like this (this is no real code, I just want to demonstrate how
it looks like). The manager accepts one connection (through many layers of
abstraction, actually), creates an instance of your request class and calls
response() on it.
Well, that's not a problem, is it? Well, it gets to a big problem if you want
to be able to handle multiple requests at once, speaking of
multithreading/concurrency here. It is a huge mess! My codebase exists of
three classes, actually. A ThreadedRequest class, a BlockingQueue where
requests get stored thread-safe and a RequestDispatcher which is a singleton
which runs several worker threads. These worker threads take the requests out
of the queue and process them if they can.
The ThreadedRequest class puts itself into the queue, which is a member of
the RequestDispatcher singleton instance. The problem is not that it is
unnecessarily complicated to build these 1-N multiplexing thing, but that the
library provides an interface which enforces you to couple your classes
realy tightly. And this is freaking bullshit.
So, finally: I'm building a wrapper lib around fastcgi++ to be able to handle requests in a concurrent way. And it sucks. But it works.
So, my conclusion is: Stay away from this bullshit library. And even from fastcgi if you can. Apache for example offers a way to write modules, so you can simply write your own module for apache if you need to – which is faster anyways!
If you have to use fastcgi, consider writing your own library!
tags: #c++ #linux #server #open source #programming #software