Partial fix for a problem with AOF and BRPOP. We have at least a single evidence of an AOF that ended with a BRPOP call against an empty list, causing later issues at run time. Now the problem is detected while loading the AOF at startup, even if it is still to understand how the corrupted AOF was generated.

Use a safe iterator while saving the DB, since the getExpire() function will access the iterating dictionary.

INFO now contains the time (in usecs) needed to fork() in order to persist. The info is available in the stats section of INFO.

Revert "Now maxmemory, VM, and everything else uses the fast RSS memory used estimation instead of raw memory reported by zmalloc(). This means that setting maxmemory to 2GB will really have the effect of using up to 2GB of memory."

This reverts commit a3e60027.

Now maxmemory, VM, and everything else uses the fast RSS memory used estimation instead of raw memory reported by zmalloc(). This means that setting maxmemory to 2GB will really have the effect of using up to 2GB of memory.

Fixed a crash loading the AOF file containing MULTI/EXEC, a result of WATCH implementation. Test needed...

networking related stuff moved into networking.c

moved more code

more work on layout of source code

SDS instantaneuos memory saving. By Pieter and Salvatore at VMware ;)

cleanly compiling again after the first split, now splitting it in more C files

moving more things around... work in progress

split replication code

splitting more

Sets split

Hash split

replication split

even more splitting

more splitting

minor change