job process supports multi-threading.

[JacksonXu761]

Because it does not support multi-threading, in reality, the current inability to print multiple jobs simultaneously is equivalent to the inability to handle multiple clients at the same time.
Is there any plan to consider adding this new feature?

[michaelrsweet]

OK, I've moved this over to the discussions area since it isn't a bug/issue.

For starters, the lack of (or minimal) use of multi-threading in cupsd does not prevent multiple jobs from printing simultaneously nor handling multiple clients at the same time. CUPS was designed in a time when computers often only had a single CPU core and far less memory than we have today, so the CUPS library's HTTP API is built as a finite state machine and cupsd uses non-blocking I/O whenever possible (there are a few places where blocking reads are required but short timeouts are used). This allows cupsd to easily handle thousands of simultaneous clients.

Job processing happens in separate (lower/restricted privilege) child processes which relay status updates via a shared pipe, allowing multiple printers to be printing something at the same time. The only thing we don't currently support is processing multiple jobs for the same printer, and that is because it has never seemed to be a useful optimization task - few printers support spooling of multiple jobs and there would be challenges in guaranteeing the order of the printed jobs, rolling up the remote printer/job status information, and making sure accounting and other features are applied accurately.

CUPS 3.0 will be based on the PAPPL library which provides a multi-threaded server implementation and potentially will scale larger than cupsd. I say potentially because we are still limited by the number of available TCP ports (~63k connections per address), file descriptors (typically a few thousand, although this can be configured), and memory (at least 64k per connection, more when receiving document data).