As a speed issue, you should definitely consider a better form of IPC. You say that you fork off the server and clienst, this will probably mean that they're on the same computer ;so using a TCP socket is a real waste of time and complicates things unnecessarily. You guys are even giving him advice against a local domain socket (UNIX domain socket) which will speed up the communication by at least a factor of 6! Of course, the fastest IPC is shared memory created by memory mapping a file (
mmap). But judging by your current design, you should go for semaphores in shared memory or the current library that provides system-wide semaphores (which will take care of the mmap). On POSIX systems, this will be <semaphore.h> and perl supports only SysV sems via
IPC::Semaphore (for those crappy and bulky SysV semaphores) or you can try the
Thread::Semaphore which does not require you to have any more than one thread and simplifies things quite a bit though it does not provide system-wide sems. Just remember to make them systemwide for your multiple processes (which on POSIX systems will become a path and on SysV an IPC object viewable with -wow-
ipcs at the command line! Remember, THERE IS NO REASON TO USE SOCKETS ON THE SAME COMPUTTER (sic). (Exception: generic client not optimzed for use on same computer, only multiple computers which is the way most games are setup so it's not waiting on I/O on a socket and some other IPC.) If you really want to get intense, you'll check out
IPC::Msg which is probably more than you need for this simple client/server arrangement. (Most systems provide also for system-wide pipes called FIFOs.)
I see this only all too often. A lack of POSIX functions forces me to revert to C/C++. O, shame! Perhaps I'll extend the
POSIX library which is very poorly arranged indeed!
