[cups.general] Concurrent IPP transfers and other CUPS operations

[Michael R Sweet]

Tim Waugh wrote:
> ...
> In fact there are several situations in which handling one IPP request 
> blocks the scheduler for potentially large amounts of time, preventing 
> it from servicing both jobs and other IPP requests.  One such situation 
> is when fetching lists of jobs, for example:
>   http://cups.org/str.php?L2913
 >
> Ideally, IMHO, this would be handled using the 'worker threads' 
> paradigm, but unfortunately that's not the way cups works.

Worker threads would have the same issues as the FSM we use today
since we'd still be blocking on reading the job history data or
waiting for a job object lock to become free.  Threading is not a
"fix all" for concurrency, particularly when you have a lot of
internal state, and creating 1000 threads (with 1000 stacks and
1000 sets of per-thread data) to support 1000 client connections is
far less CPU/memory efficient than a single thread supporting the
same load.

Hybrid approaches are of course possible, and Apache is an example
of how you can do it, however we'd still need to offer a non-threaded
mode for OS's that don't do threads well enough to handle signals at
the same time (which includes Linux in the not-so-distant past...)

-- 
______________________________________________________________________
Michael R Sweet                        Senior Printing System Engineer