Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#254 closed enhancement (worksforme)

Improve IPC terminology

Reported by: Martin Decky Owned by:
Priority: minor Milestone: 0.4.3
Component: helenos/unspecified Version: mainline
Keywords: Cc: jakub@…
Blocker for: Depends on:
See also:


It has been suggested multiple times (several times by Petr Tuma) that HelenOS-specific IPC terminology is somewhat strange in that sense that it uses unusual terms for common concepts. Therefore I suggest to gradually replace our specific terminology by usual one, somewhat in the line of:

phone = connection
call = message
reply = response (reply is still OK)
answerbox = message queue (mailbox)

If there is a good reason why we should prefer to stick to your current terminology, please elaborate.

Change History (6)

comment:1 by Jakub Jermář, 14 years ago

Frankly, I don't like the suggested idea for the following reasons:

  • the new names are not 100% equivalent with the old ones.
    • A phone should not be confused with a connection, because at best it is only one end of the connection and answerbox_t is the other one.
    • The phone structure usually survives the connection and lingers in the hung-up state for some time or it may never be connected
    • It may even be slammed while the client is still attempting to 'make some calls' over it, so there is a phone, but the connection is gone
    • When you say that task A has a connection to task B, it is not as descriptive as saying that there are five open phones from A to B
    • An answerbox is a collection of message queues rather than a single message queue (or using the term message queue would be confusing too).
    • Neither mailbox is a good metaphor because it lacks the FIFO characteristics
  • I perceive it like that our names: phone_t, answerbox_t, call_t etc. denote concrete implementation of concepts of connections, message queues and messages and can be explained or clarified using the standard terms
  • I am already familiar with the terminology and by giving it up, HelenOS would lose a bit of its uniqueness
  • The weakest chain in the terminology is probably call, but when one realizes that it is a call recorded by the answerbox, its use is IMHO justified
    • async framework uses the term message for a higher level construct based on calls, so it is already taken
  • I don't believe that phone, call and answerbox is such a big problem for anybody who has at least a theoretical chance of understanding the rest of HelenOS source code or its architecture

comment:2 by Jakub Jermář, 14 years ago

Cc: jakub@… added

comment:3 by Jakub Jermář, 14 years ago

I can also see one additional advantage to using non-conventional names for the concept of connection, message and mailbox - out of box thinking. That is, if we use a similar, but still different metaphor for the three than anyone else does, we may be looking at the thing from a different perspective and thus have some potential of brining new solutions to some of the classical problems.

comment:4 by Jakub Jermář, 14 years ago

The suggested terminology is not being used even in the archetypal Mach microkernel:

(send) right ⇒ connection
port ⇒ message queue

comment:5 by Jakub Jermář, 14 years ago

Resolution: worksforme
Status: newclosed

Under the weight of the above evidence, I am proceeding to closing this ticket as worksforme. If you disagree, feel free to provide further evidence and reopen.

comment:6 by Jakub Jermář, 13 years ago

Type: proposalenhancement
Note: See TracTickets for help on using tickets.