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!