0

I'm tasked with designing a small daemon (on Debian Linux) which will use a blackbox libfoo.so to communicate with an external EFT terminal. There are several, identical EFT terminals (around 100), and one libfoo.so instance can only communicate with a single terminal. There is an init call which essentially binds the instance to a terminal.

We're mainly using Java in our company, but this probably calls for a C++ implementation. The programming language is not yet defined.

As we'll need to handle concurrent communication with multiple terminals (around maybe 10 concurrent threads), we'll need to load several instances of the libfoo.so. I'm looking for design principles how to solve such a requirement (dlopen will only load an SO once, same thing for JNI). Do I need to spawn child processes? Copy/paste the SO and call it libfoo_1.so, libfoo_2.so etc. (aargh!) Are there other solutions?

Thanks

Simon

Simon
  • 2,994
  • 3
  • 28
  • 37
  • When you say "blackbox", do you mean the shared object has no API whatsoever ? – SirDarius Jan 24 '14 at 08:56
  • Sorry about being imprecise when using the "blackbox". The SO does have an API, however, we don't have the source code, and cannot influence the API. – Simon Jan 25 '14 at 14:00

1 Answers1

0

If the library has no API, meaning it runs its code using the .init mechanism, then you have no better choice than forking a parent process and dlopen the library in the child processes.

This is pretty simple actually, as long as you remember to wait for your child processes to terminate when needed.

If you need to handle communication between your parent and child processes, there are several Inter-process Communication methods available such as pipes.

Community
  • 1
  • 1
SirDarius
  • 41,440
  • 8
  • 86
  • 100