[squid-users] Squid 3.5 with nonblocking ecap adapter

[Yuri]

01.11.2017 23:37, Alex Rousskov пишет:
> On 11/01/2017 09:26 AM, Yuri wrote:
>>>> 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.
>> AFAIK B) is impossible.
> It is not only possible but implemented in sample and production
> adapters (as I have said later in the same email).
"Stop talking - just show the code." :) (Ideally - in C++, not in C. And
not adapter sample - it's illustrates nothing because it is mixture of
C++03 and pure C pthreads).
>
>
>> I see no way to push body from ecap library to adapter at whole, not
>> chunk.
> This part of your assertion does not compute for me:
>
> * First of all, it seems completely unrelated to the OP question.
>
> * Second, the body is not pushed "from the eCAP library". Body bytes are
> "pushed from" ("made available by" would be a more accurate term) the
> host application (e.g., Squid) to (for) the adapter and vice versa. The
> amount and timing of body bytes availability are determined by the side
> doing the "pushing" and, naturally, body data presence on that side.
Do not cling to words. You understand what I mean. And, for that matter,
yes, the host gives the body - but through the library. If I understand
the design correctly. Otherwise it is not clear, what does the library
have to do with and why is it needed?
>
> Many adapters "stream" message content (processing each body piece on
> the fly) and some adapters accumulate whole bodies before acting on
> them. The best design depends on the adapter purpose and various
> risk/resources/performance/complexity trade-offs.
>
>
>> I see no documented way to do this.
> Asynchronous adapter API is documented in libecap/doc/async.txt. There
> are no detailed tutorials, but there is working code to study.
Seriously? Here is a text file with common words you call good
documentation?
>
> There is no documentation dedicated to body exchanges, but each
> adapter::Xaction::ab*() and host::Xaction::vb*() method is briefly
> documented and there are public working adapters that illustrate the use
> of those methods.
The key word is "briefly". How much public working async adapters do you
know? Which I can study?
>
> If you have questions specific to eCAP, then this Squid mailing list is
> not the right place to ask them, but see http://www.e-cap.org/support/
>
>
>> And it does not work for a much larger number of cases due to library
>> limitations.
> AFAICT, you are conflating developer failures with library limitations.
> The eCAP library is far from perfect, but it does not have the flaws you
> allege.
Ha. Ok, let's agree on it.
>
>
> HTH,
>
> Alex.
>
>
>>> 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.

-- 
**************************
* 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/9bac3adb/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/9bac3adb/attachment.sig>