We want a factory F which produces X’s which among other things, are notified of certain events in the world to which an X must not send information.
Notification patterns sometimes include means for delivering fresh information with a notification.
Other patterns give the recipient only a clue that it is time to look for new information thru means already held by the recipient.
As a general problem it seems to me just now (2006) that a small amount of new user code must be produced and trusted by those who want such a feature.
A single new trusted object type, implemented in user code, can serve all such requirements.
It must be relied upon by those who provide code that needs such a communication channel, and also by those concerned with the nature of the confinement.
A notify relay, NR, is hereby defined which is an object (made of one domain) to which there are two start keys, P and Q.
{P is designed to be held by the object that must produce notification.
Q is designed to be held by the object that must receive notification.}
An NR has two states abstractly; it holds a resume key, or not.
When P is invoked, the NR forks its resume key, if any, passing the data of the message and sensory versions of the keys from the message.
The NR then returns a null message to the invoker.
When Q is invoked with a resume key, NR keeps that key as its resume key and returns.
If any other sort of key is passed via Q no change is made to NR’s state and an error return is made to the invoker.
There is public source, NRC, invocation of which returns two keys, P and Q to a new empty NR.
To solve the original problem the program that needs a discreet notified object and has access to F and NRC does the following:
- Invoke F which yields f, which as yet lacks means of notification.
- Invoke NRC and accept P and Q to a new NR.
- Pass Q to f, which is expecting such a key.
Presumably f creates a domain which calls Q and upon return, is thereby notified and performs any acts appropriate to a notification.
- Pass P to some (non-discreet) service for notifications.
The service providing the notification need not be trusted not to receive signals via P for P always promptly returns an empty message.
For assurance of discretion, the program that takes these actions must trust NRC and verify that F is a factory.
The code for NR is about 100 instructions and a domain obeying those instructions needs no read write storage depending on the language it is written in.
If data are allowed thru the channel writable storage may be needed.
It would consist of one domain and a read-only page shared among all NRs, to hold those 100 instructions.
In assembler the source for the code would be smaller than this page.
Critique of Above
The notifiee and notifier in the above scenario seem incompatible.
The proposed new type NR mates them as an adaptor mates two incompatible power plug standards.
There is no function in the null messages that travel in the prohibited direction.
It might be easier to remove them than to ensure that they were null.
It would almost certainly be more efficient.
It would also be nice to establish a general protocol between notifier and notifiee that allows a intermediary that, unlike NR, is merely transparent.
Google quickly shows that there are many notifier patterns among which our proposal above is rather elementary.
Many of those include a broadcast function so as to off-load that logic from the source.
That seems orthogonal and I won’t consider it here.
I speak now in terms of delivering a stream across a trust boundary where prompt delivery is at least part of the purpose of the stream.
So far we have implicitly assumed that the sender is not blocked on a slow receiver.
I continue to do so at least for a stream flowing into a discreet object; blockage is a counterflow signal.
Shap’s proposal allows a reusable start key that could be held by a police intermediary to deliver messages into the discreet world.
If the intermediary selects the non blocking option, it will itself be prompt.
In notification pattern two above the recipient must use his “other means” to read changing without benefit of read locks, for even read locks violate the stricture on outflowing information.
There are simple schemes to do this but they do not suit all applications.
Sometime the nature of the changes is irrelevant to the reader.
For instance reading the temperature stored in one mutably byte does not require a read lock.