C Development

Cons

Problem	Possible solution
too many libs should be written / learned/ troubleshooted / integrated (XML parsing, Logging, exception handling, mailing, accessing DB, etc)	many of these are already written. for example we have a DBWrapper in C already integrated in RDAM/NetFind. MySQL itself has both C and C++ API (the C++ API is very natural to use template base STL-style class library), all the DCP/RDAM internal C part uses Logging module in C. As for the XML Parsing, there are many unclear things in present configuration format and this could be the time to change it a bit. I was thinking from the very beginning that Apache-like config file would be much more clear and having XML is more functional maybe but definitely clumsy (TBD)
not an easy way to add plugin	again the Apache-style architecture will do. different plugins can be implemented like shared object libraries (.so) and dynamically loaded by framework (dlopen()) after configuration parsing. this will only add load during init. after they are mapped in proccess address space there will be no difference, e.g. same as Perl
compilation / installation become harder	yes, it does. still a good configure + makefile will make it no different than Perl thing
big development time	once the framework + one or two more significant plugins are developed and well tested, the rest is easy to implement
less people in the office can write plugins	still enough, I guess
tough times making the code memory leakless	considering reentrancy restrictions, most of data will be on the stack and the rest will be carefully synchronized, e.g. this won't be that hard to take care of
more platform dependant	this holds for Perl also (though in less degree)

Pros

Plus	Description
efficiency	no other possible solution could ever be faster than good-written C code. most of calls (socket functionality) will be native system calls and this could be no better. memory needed will be much less, than Perl solution. C implies that good algorithms are used to manage data.
secure	since C is the Linux kernel language, and so much network software is written in C, the chance we come up a gap which could trap the development (as Perl threads already did) is much much less. I believe most of the language problems have already been discovered and fixed
no need to change platform	the Perl solution needed multithreaded Perl compiled on machine and Perl by default compiles singlethreaded. Which means that Perl WatchCub could run either on a special machine with different perl compiled or to live n the same machine having both single- and multi-threaded versions compiled. (multi-threaded version is considered experimental which makes it non-appropriate for production servers). a C solution won't need any specifics (except glibc-2.2+ which comes by default with most linux distributions)
natural development	when writing network applications C is probably the most natural language to use. packet packing and unpacking in Perl is considerably strange and makes the software totally platform dependant (you have to know what's the length of the structure, every field etc...)

Perl Development

Of course all of the above hold. Some additional:

Pros

Problem	Possible solution
non-reentrant	this means that even almost complete synchronization won't do. which not only leads us to single-threaded (asychronous) plugins, but implies process forking.

Hybrid Version

I don't believe this is a good idea. While trying to make perl version safe I reached a moment when I had locked almost everything which could possibly be locked. And still some problems occurred from time to time.

Besides, the fact that every Perl socket API function is potentially non-reentrant leads us to making every single module in C and then wrapping it in XS, because if even two (possibly different) modules use it in different threads data mess-up is almost guaranteed. After we do that we should make the framework reentrant and this is not very easy since we don't know where problems are possible.

In fact after I read all the stuff in forums all over the Internet, I think Perl is not a good idea for multithreading.

It would do if this was some easy nonimportant task but if we are to put this software on production server to watch after commercial software, I think we should make sure it is as stable as we want our products to be.

Open questions to discuss on

1. What are the chances we save/reuse some work already done
2. If we switch to C development we should decide C or C++ (in my personal opinion, object oriented code will be better for development). Idea: Finite state machine tests could be developed as some basic class providing most of functionality with sockets and states. After that, every asynchronous test can be derived from this basic class. I found C++ better because we can use STL, which provides as templates most of the data structures needed. This will make the development a lot faster.