[squid-users] Squid 3.5 with nonblocking ecap adapter

[Yuri]

01.11.2017 21:23, 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).
This is absolutely not necessary. The interface of the store ID allows
you to write a threaded asynchronous (thread-aware) helper in
combination with a thread-unaware. This allows its interface. However,
the eCAP interface does not allow this because of the synchronous nature
of the ecap library and this restricts of its interaction with the host.
About this OP asks exactly.
>   B) Use threads inside the adapter to make its operations asynchronous.
>
> As you know, the sample async adapter and the ClamAV adapter use (B).
This sample useless on whole class of cases. For example, it will not
work with gzip compression. I've spent much time in attempts to make
gzip adapter threaded/async. Without any success.
> 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.
And it does not work for a much larger number of cases due to library
limitations.
>
>
> Cheers,
>
> Alex.
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-- 
**************************
* C++: Bug to the future *
**************************

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x3E3743A7.asc
Type: application/pgp-keys
Size: 2887 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20171101/3a0b5d91/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20171101/3a0b5d91/attachment.sig>