Multithreaded Input Mode
By default, kdb+ is a single threaded process, and will process incoming queries sequentially.
An additional mode exists, the multithreaded input queue mode, which is designed for serving in-memory static data to an externally constrained number of clients only; it is not intended for use as a gateway, or serving mutable data, or data from disk. Each incoming connection is executed in its own thread, and is unable to update globals - it is pure functional in that sense, that the execution of a query should not have side-effects.
There can be a maximum of 1020 concurrent connections, with each connection requiring a minimum of 64MB, the real amount depending on the working space required by the query being executed. Each connection has its own thread, which is either reading, calculating or writing a response; in addition there is the main thread, which monitors stdin, invokes .z.ts on timer expiry and monitors other socket descriptors (there should not be any). Updates to globals are not allowed unless they occur from within .z.ts, and even then they should not be frequent as the timer expiry waits for completion of exiting queries, blocking new queries (using multiple read single write lock). If an attempt is made to udpate globals from threads other than main, they should get a 'no update error. If an update came in via the console, or via a socket being processed by the main thread, currently these updates are not thread safe.
The switching in and out of this mode now checks to avoid the situation where the main thread could have a socket open, and sockets being processed in other threads simultaneously.
Multithreaded input queue mode is active when the port for incoming connections is specificied as negative, e.g. for startup
q -p -5000
Some of the restrictions are:
- queries are unable to update globals.
- .z.pc is not called on disconnect.
- .z.W has a view on main thread sockets only.
- cannot send async messages.
- cannot serve http requests.
- views can be recalculated from the main thread only.
The use of sockets from within those threads is not allowed for anything other than the recently added single shot sync request in 2.8:
2012.02.05 NEW allow single shot sync request as `:host:port:user:password data e.g. q)`:localhost:5000 "2+2"
which is the only socket op supported in multithreaded mode (but inefficient as it opens, queries and closes each time).