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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
