I have a question about callback in multiple processes situation, as following.
There are one dynamic lib and several , e.g. 3, processes. During startup, each process registers a callback entry with this dynamic lib for handling message from specified UDP port. The lib listens
to the specified UDP port and if any message is detected the callback selected based on message type is called to handle the message. Obviously, all processes share same lib instance in memory and callback entries may point different process.
Is the problem clear enough? Here my question is whether such software design works well? If yes, what should be focused on?
You may give me your comments and advice based on your Linux experience.

Recall that a library is not an independent execution-unit: it is a block of code that executes within the context of each thread or process that uses it.

So... the library doesn't "listen to a port." The library might contain code that listens, but that code will be executed in the context of someone who has called the library routine.

Alternatively, the library might contain code which spawns a dedicated thread to do the listening. This creates a fourth independent execution-unit, also attached to the same library, which is responsible for executing the "listen" routines. Now the library has four clients: three who have registered ports and are now parked in "wait for something to happen" code, and a fourth (the thread) which is listening and will eventually call the "say, something interesting just happened, go wake someone up and tell them about it" code.

sundialsvcs
Firstly thank you for reply. Here I have the other question as follow.
Let's assume there are 3 processes(P1,P2 and P3) which register 3 callbacks(callback1,callback2 and callback3) with tm.so and a dynamic lib tm.so including a thread for listening to UDP port. The 4th thread is a good idea. If P1 is running and tm.so receives a message belonging to P2 and callback2 is called, what happens?
Can this situation push scheduler to transfer control to P2? If no, how is callback2 activated under above situation? Callback2 belongs to P2 and P2 is not running.
I have not idea.
Thanks

Scanner -

If you come from a Win32 environment, please be advised that there are some significant differences between a Windows .dll and a Linux shared object

Here is a great overview of the entire subject - this link will almost certainly answer most of your questions:
http://en.wikipedia.org/wiki/Shared_library)

Here are a couple of other links that give some more detail:
http://yolinux.com/TUTORIALS/Library...ndDynamic.html
http://docs.python.org/ext/dynamic-linking.html

The answer to your second question is the same as sundialsvcs' response to your first question:
In other words, the socket you have listening on the UDP port is allocated *by that process*, it is *not* available (at least not without a lot of extra work that's outside the scope of this topic) to any *other* process. The callback (which happens to come from your shared library) is part of that process's address space. It is *completely separate* from any other process's callback in any other address space (even though it might happen to be the same function from the same shared library).

*Physically*, sure - the code might be "shared". *Logically*, however, it's completely separate. As far as you and your program is concerned, there is *no* sharing between P1, P2 and P3 (as long as they're separate *processes*).

Does that help?

PS:
Threads are a whole different ballgame. A considerably more *complicated* ballgame...

Probably what you should do is to conceal all of the communication and synchronization mechanisms needed by the various clients into the library.

A client calls one library function to "open communications," and another to "wait for a message to arrive and then collect it." Beyond that, all of the implementation details are opaque.

When a process or thread "waits for a message to arrive," basically it goes to sleep until the listener-thread is informed that some traffic has arrived. Then the listener wakes-up the other thread.

The "wait for a message" routine (executing in the context of the waiting thread) sleeps, say on a mutex, then collects the message. All of the details of "how this is done" are encapsulated in the library and opaque to its callers.

Scanner -

Please make sure you know how a shared library works, before you go designing a whole architecture for your application. Please do yourself a HUGE favor and glance at one or two of these links first:

http://en.wikipedia.org/wiki/Shared_library
http://yolinux.com/TUTORIALS/Library...ndDynamic.html
http://docs.python.org/ext/dynamic-linking.html

As far as "architecture", the first question you'll need to ask yourself is:

a) Can I solve the problem in one, single process?
b) Would I benefit from multiple threads?
... and/or ...
c) Should I instead use multiple processes

And of course your knowledge of shared libraries will help you in each of the above choices ;-)

IMHO .. PSM

My problem is limited to Linux platform(version and later).
For now, with your help, I think I have gotten it. A dynamic/shared lib is shared "physically" and separated "logically". And my problem, living in some processes, should belong to "logical" and so my software structure mentioned above work no way, at least not in expected way.
Anyway thank you gurus!!!