Jonathan S. Shapiro
Wed, 09 Sep 1998 13:25:02 -0400
[I'm forwarding the following on behalf of Charlie Landau. His email
address changed with the compaq acquisition, causing the original to
bounce. Now fixed].
From: "Landau, Charles" <email@example.com>
To: "'firstname.lastname@example.org'" <email@example.com>
Subject: RE: Proposal: events
Old-Date: Tue, 1 Sep 1998 11:50:11 -0700
X-Mailer: Internet Mail Service (5.5.1960.3)
X-Diagnostic: Not on the accept list
Since you said "I'm sure the details are not right" (I agree), I'll stick to
the broad issues in your proposal.
Let's consider your example in which there is a "driver" and several
"clients". The driver's goal is to ensure that one client can't impede
another. There are two basic ways in which the driver can ensure this.
(1) The driver takes responsibility. It creates the objects necessary to
ensure promptness. In your example, the driver would "create a per-client
thread and kick-start that thread, which in turn kick-starts the client."
You've omitted some necessary detail in this description, but the method
(2) The client has responsibility. It must create the objects necessary to
ensure promptness. The driver then must validate that the necessary objects
have been provided by the client. In your proposal, the client provides a
On the face, (2) is more complex. And there is a more fundamental objection.
There can be no simple definition of "prompt". Does the driver require
scheduling guarantees? Can it wait for objects to be fetched from disk? Is
there a set of threads whose behavior is prompt enough that they can safely
be called synchronously (this set probably includes the stuff on the side of
the driver opposite the clients)? What if the client is on a different
processor or elsewhere on a network?
Since there is no simple definition of "prompt", it is unreasonable to
expect the client to provide objects with the type of promptness required by
the driver. It would make the interface too complex.
Your proposal doesn't adequately address the question of validation, either.
You propose a new "post" operation, without being clear about its semantics.
The call, fork, and return operations all basically just send a message to
the target object. If you are proposing a new type of message, you would
have to do a lot to justify the additional complexity. You would have to say
how the existing objects respond to such a message, and you would also have
to explain the implications for transparent intermediaries.
By the time you're done, I think you'll find that whatever "concurrency
management problems" you ran into with the original approach pale in