Asked by Alan on 2010-09-02

When squid sends a message to the eCap service, does it run the service in a new thread, or in a new process, or does it block until the one and only copy of the eCap service returns ?
Should I write my service in a particular way to be able to handle multiple threads or will squid simply cause separate copies of the service to run, one per request ?

I'm trying to achieve a system where the cache is able to process multiple transactions in parallel. I've seen similar systems, like squidguard, where a number of servers will be spawned and work split between them. Or in remote icap (or even http) servers, they would notmally handle the threading themselves to handle multiple requests in parallel. Is any such thing necessary for eCap too ?

Many thanks

Question information

English Edit question
eCAP Edit question
No assignee Edit question
Solved by:
Alex Rousskov
Last query:
Last reply:
Best Alex Rousskov (rousskov) said : #1

eCAP is threads-agnostic, at least for now. It does not assume that the host application is threaded. It does not require the host application to use threads. Your eCAP adapter code must not block. Your adapter may use threads or other tricks to achieve that.

Individual eCAP adapter transactions must be prepared to be executed in a threaded or multi-process host environment. For example, if two adapter transactions write into the same file, they must protect the file from corruption.

Squid core does not use threads (yet). Squid uses an I/O loop design to process multiple transactions concurrently. Recent Squids also uses multiple processes for SMP scalability.

Alan (007badguy) said : #2

Thanks Alex Rousskov, that solved my question.