|Perl: the Markov chain saw|
When thinking threading, I always viewed it in the eyes of user threading like in Java.
The main limitation of java-style user threads is that there is no true concurrency. No matter how many cpus or cores the machine has, a Java app will only utilise one of them at a time no matter how many user threads it spawns. Therefore, you can never scale the app by moving it to a multi-cpu system.
That same limitation is what allows Java threads to be very lightweight and efficient. As only one thread is ever truely running at any given moment, many of the consideration for locking required by apps utilising kernel threads simply do not arise.
It's a swings and roundabouts argument. What you gain in one place, you loose in another.
Your 'spec' is still pretty sketchy, but if I'm reading between the lines correctly, I would say that what you want to do is eminently doable with iThreads.
To be sure, I would need further details including the number of systems you are talking to concurrently; the nature of the data you are sharing etc.
Not only does it sound doable, it sounds pretty straight forward.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.