[squid-users] Squid 3.5 with nonblocking ecap adapter
Yuri
yvoinov at gmail.com
Wed Nov 1 15:26:39 UTC 2017
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).
> B) Use threads inside the adapter to make its operations asynchronous.
Alex, AFAIK B) is impossible. Because of I see no way to push body from
ecap library to adapter at whole, not chunk. Or I am stupid bastard? I
see no documented way to do this.
>
> 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.
> _______________________________________________
> 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/9d57c470/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/9d57c470/attachment.sig>
More information about the squid-users
mailing list