kdb+ 32-bit, what are the consequences of the 4GB restriction?

Question

I'm trying out kdb+ and I found out that the most common way to communicate with a program is to open a socket on port 5001 like so:

q -p 5001

Now kdb+ has built-in functionality for multi-threading called peach. According to their documentation, from version v3.1 peach will automatically:

Since v3.1, peach can use multiple processes instead of threads, configured through the startup cmd line option -s with a negative integer, i.e. -s -N, e.g. -s -4. On startup, kdb+ will then try to connect to N processes on ports 20000 through 20000+N-1, and use of peach with >1 element will use those processes to execute the function given to peach.

I was wondering, could I also do this manually?

I am currently running the 32-bit version of kdb+ (up to 4GB of memory per process) and according to this post, you can work around the 4GB restriction by using a multiprocessing system.

So what exactly does multiprocessing mean? Do I need to start N instances of kdb+ on different ports (like peach) to get a N x 4GB in-memory application or is the 4GB limit simply a restriction on something else?

So on what exactly is this 4GB a restriction? Do I need to open multiple ports?

Edit

This website seems to confirm that for multiple processes and inter-process communication, I need to open multiple ports on different addresses.

So is each instance of kdb+ considered to be a process?

Answer 1

Correct, a kdb+ instance is a whole process in its own right, with a port number set at command line by yourself.

You can't do peach over a number of handles:

handles:hopen each someList;
{x"do some work"} peach handles

You'll get noupdate, so would seem you can't do this manually. There is a handshake on hopen so even if there are other processes running on that port range, kdb would know which ones are kdb (I guess it would capture an error on hopen... but I've never tried it)