Shirley <novice@hongkong.com> wrote:
Is there any function for a server to reply a message to ALL of its client
at the same time?
e.g. server need to send a kill message (which carry some SPECIFIC
information to its client), and then kill itself.
It seems to me that server can only reply its client, so it must wait for
MsgSend() from its clients before it can kill them … but what if only one
client invoke the killing action? The other clients will not know and so
will not send a “commit suicide” signal to the server…
Hi Shirley
Let me give you a quick lesson in messaging 101.
Any thread can send a message to any thread. But that doesn’t mean
that it should. Take this simple case:
Thread A sends a message to thread B. Thread A is now SEND BLOCKED.
It can’t do anything until thread B replies. (For now, we’ll ignor
the conccept of being interrupted by a signal.) Now thread B secides
to send a messaeg to thread A and thread B is now SEND BLOCKED.
This is called a deadly embrace. Both threads are hung waiting for
the other thread to reply to their message, which won’t ever happen.
This is a RBT! (Really Bad Thing)
The design I have always used is that you have lowest lever servers
that will only send messages to QNX OS stuff (the file system). They
never send to a client. They can reply to a client, but the client
must send first. The picture is that a client sits at a higher lever
than the server. Your client may be a server to some other threads.
This is allowed as long as your sends are always only in the down
direction.
HOWEVER, it is important to maintain the real-timeness of a system. So
you never want a server thread waiting longer than the briefest
instant for another server thread to reply to it. While it is waiting
it is helpless to reply to any of it’s clients!
What I do is this. Each client defines a ‘struct sigevent’ and sends
that to it’s server when it establishes it’s connection. The server
replies immediately with a “ok” or some error code. From now on, any
time th client sends a message, the server replies immediately. If it
can honor the request immediately, it does. If it can not, it replies
immediately with a code that says “I’ll let you know when it’s done”.
[time passes]
When the server either successfully completes the requests or fails
to complete the request, it sends the sigevent back to the client.
This is a non-blocking send. The client doesn’t reply to it.
The client gets this segevent and know that one of it’s outstanding
requests has either succeeded or failed, so it send a new request to
find out which request and how it has completed, success or failure.
Now the server thread can immediately reply with any necessary data or
error codes that the cleint needs to know about. Everything stays
very real-time.
For a better overview of all of this look at the helpviewer page for
MsgDeliverEvent().
Good luck.
–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net