HTTP API and blocking

[David Benjamin]

Hi,

I was looking into a problem where the GTK+ printing dialog sometimes hung waiting for CUPS printer information, and ran into problems with the HTTP API.

>From what I understand, GTK+ interacts with CUPS in the same thread as the GUI. It attempts to integrate the relevant file descriptors and such into the event loop, or something of the sort --- I think it might actually be polling even. It forgets to set the http_t to non-blocking with httpBlocking (http, 0) when requesting a PPD, but even when fixing that, the call blocks.

Source-diving in CUPS, I see many lines like

    if (!http->blocking && !httpWait(http, 10000))
      return (0);

which suggests that we wait on the socket if it is /not/ blocking. The socket itself does not appear to be fcntl'd to O_NONBLOCK, although there is a preprocessor block at the top of http.c bemoaning the lack of a FNONBLK macro. The redefined macro itself seems not to be used.

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?

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? (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?

Thanks!