[squid-dev] Squid 3.5 with nonblocking ecap adapter

[Alex Rousskov]

On 11/02/2017 03:49 AM, Christof Gerber wrote:

> One thing I still don't fully understand is if the asynchronous way to
> program and operate Squid with an eCAP adapter necessarily relies on
> threads?

No, threads are just one popular way to achieve asynchrony. One may also
use multiple processes or (for some definition of asynchrony) event loops.


> Are A) and B) alternatives or the only options?

If you replace B's "threads" with "threads or other asynchrony
mechanisms", then yes, IMO. Threads are probably the most popular way to
achieve asynchrony in new code.


> I've seen that both the
> ClamAV and sample async adapter use pthreads. In my use case I need to
> do a simple hash lookup to a file socket somewhen during the eCAP
> interaction. As it will take some milliseconds until the response will
> be available on the socket I don't want to block Squid during this
> time. 

Yes, this is a common problem.


> But the eCAP adapter won't need to process/compute anything else
> during this time. So why would I bother to use threads? 

... because without threads (or processes or event loops) your adapter
lookup will block the whole Squid worker while waiting for socket I/O.

If you do not want to use threads or processes in your adapter, then you
can try to use an event loop model. That is what Squid uses internally
(each Squid worker does not have threads to process thousands of
transactions "concurrently").

To use an event loop model, your adapter will need to use non-blocking
socket I/O and schedule _one_ I/O loop iteration every ~X milliseconds,
when Squid calls your Service::resume(). Try googling "I/O loop" or
"select loop" for starting points if you are not familiar with that
design pattern. The overall host-adapter interaction would be very
similar to what you find in the sample and ClamAV adapters.

Disclaimer: I have not seen anybody using event loops with eCAP. I think
it is possible to implement that model, but there may be important
caveats that I am not aware of.


HTH,

Alex.


> On 1 November 2017 at 16:23, Alex Rousskov wrote:
>> 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.