Sharing code and data across eCAP adapters

Asked by Jatin on 2019-12-19

The host application (squid) loads the ecap adapter module and I wanted to understand if its possible to share some objects instances across all the loaded modules. I have to create scanning objects which holds a lot of memory for each of the module loaded. Is there any way to share the instances in ecap. Or using shared memory object on the linux appliance is the best possible option here ?

Question information

Language:
English Edit question
Status:
Solved
For:
eCAP Edit question
Assignee:
No assignee Edit question
Solved by:
Jatin
Solved:
2019-12-19
Last query:
2019-12-19
Last reply:
2019-12-19
Alex Rousskov (rousskov) said : #1

> I wanted to understand if its possible to share some objects instances across all the loaded modules

Yes, I think it is possible. One way to do that, AFAICT, is for both adapter A and adapter B to be dependent on a third library AB. That library will contain the code responsible for sharing and will allocate/expose shared resources. Whenever adapter A or adapter B (whichever is loaded first) is loaded by the host application, the dynamic linker will make sure that AB is loaded as well. The host application itself will not know about AB existence.

> Or using shared memory object on the linux appliance is the best possible option here?

Using shared memory is also possible, of course.

Which model is the _best_ depends on many problem-specific factors.

Alex Rousskov (rousskov) said : #2

My answer above applies to one host application process loading two different adapters (A and B).

If you want to share data across different application processes (e.g., across two Squid workers), then you must use shared memory, disk files, or another global/system resource. Each process has its own memory space so adapter in process X cannot access data local to the process Y adapter.

Needless to say, sharing global/system resources across two different adapters in two application processes can still be implemented using a common library AB. That common library would expose access to shared memory (or another global/system resource) rather than to local process RAM, of course.

Jatin (jbhasin83) said : #3

Thanks Alex.

Jatin (jbhasin83) said : #4

This solved my problem