[cups.development] HTTP API and blocking

Michael Sweet msweet at apple.com
Wed May 26 11:26:23 PDT 2010


On May 26, 2010, at 10:18 AM, David Benjamin wrote:
> ...
> What are the intended semantics of a "non-blocking" http_t? Is the intended difference between CUPS' notions of blocking and non-blocking to be that in a /non/-blocking connection, you /block/ for a finite but long timeout, and in a blocking connection you just read directly from the socket?

Basically, yes, mainly because the IPP machinery can't deal with partial reads and still error-out nicely for the scheduler.  There are some things we've looked at doing to solve this issue but haven't mainly due to available time...

> In that case, this doesn't seem to be useful to needs of an event-driven GUI. Is the recommended way of interacting with CUPS in a toolkit to create a dedicated thread to block on CUPS?

At some level you will need to block on CUPS (getting PPD files, etc.), and doing the work in a separate thread from the main UI is definitely the way to go if you find a lot of users are pointing at non-local cupsd's.

> (I'm also somewhat suspicious of how well these non-blocking semantics work, since the calls to SSL_read and others could probably block on the socket, knowing nothing of the 10s timeout, if more data is needed than httpWait sensed.) Or am I understanding things wrong?


We provide our own IO layer for the SSL toolkits that provides the timeout for non-blocking http_t connections.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair








More information about the cups-devel mailing list