242248 - IPC synchronous message support needs to be reworked

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Darin Fisher]

synchronous message handling does not work well when a message target uses
both synchronous and asynchronous messages.  this has to do with the 
hackish was synchronous messages were implemented.

synchronous message handling also would not work well between two clients
of  the daemon.  consider this scenario:
    
    A sends sync message to B
    C sends sync message to A
    B sends sync reply to A

in this scenario, A receives a message from C before it receives the sync
reply from B.  the way things are now, A gets confused and thinks the 
message from C is the sync reply.  this is because the daemon marks the 
next message sent to A as the sync reply.

basically, the whole system of marking a message as expecting a sync reply
is broken by design.  a better solution is to enable A to wait for an
incoming message that matches its own criteria.  IOW, an API like this
would be nice:

    SendMessage(clientID, targetID, msg);
    WaitMessage(clientID, targetID, &msg, SelectorFunc);
     
SelectorFunc is called whenever a message arrives, and it returns a boolean
value that indicates whether or not the new message is the desired message.

this sort of API is much more flexible and robust.

---

along with reworking the client-side messaging API, i also fixed a couple
small bugs and greatly refactored the client-side library implementation.
the hope i have with this refactoring work is to pave the way to building
the IPC client library in standalone mode.  this would make it easier for
3rd party apps to talk to mozilla via the IPC daemon.

Comment 1

[Darin Fisher]

Attachment: v1 patch

note: this patch is not totally clean.	i've commented out some things instead
of removing them b/c i plan on adding them back.  i've also changed the "client
querying" API quite substantially.  now, it is only possible to query for a
client id by name.  there is no support yet for querying for properties about a
particular client.  that can come later as needed.

Comment 2

[Darin Fisher]

brendan: here's that IPC cleanup bug i mentioned.  comments welcome if you have
time =)

Comment 3

[Darin Fisher]

fixed-on-trunk... the patch that went in on the trunk is the v1 patch + various
other bits of cleanup.