[squid-users] Squid 3.5 with nonblocking ecap adapter

[Alex Rousskov]

On 11/01/2017 03:20 AM, Christof Gerber wrote:

> [Will Squid] be blocked until the eCAP API call returns?

To answer the exact question above: Yes, the Squid worker making an eCAP
API call will block until that call returns. The same is true for all
other API calls, all system calls, and all internal calls. This is how
C/C++ works. I am stating the obvious for the record, in case somebody
with a different (or insufficient) programming languages background
stumbles upon this thread.

What you are really asking, I suspect, is whether Squid or the eCAP
library uses threads to automatically make eCAP adapter operations
asynchronous to the primary Squid operations. The answer to that
question is "no": The relevant Squid code does not use threads, and
there are no threads in the eCAP library code.

Also, there is no magical layer between Squid and 99% of eCAP calls --
Squid calls go directly to your eCAP adapter code and vice versa. IIRC,
the only (unimportant) exception to that "direct calls" observation is
the eCAP service registry API, where there is a thin eCAP layer
insulating the adapter from the host application. That layer is also
synchronous though.


> Is there a way other than
> programming the eCAP adapter in asynchronous mode?

I do not think there is a better alternative. AFAICT, you only have two
options:

  A) Change Squid to move eCAP calls to thread(s).
  B) Use threads inside the adapter to make its operations asynchronous.

As you know, the sample async adapter and the ClamAV adapter use (B).
That approach has its problems (because it currently does not require
the host application to be threads-aware), but it works reasonably well
for many use cases.


Cheers,

Alex.