- issue id
AIS::InputBufferingProhibited
Summary: AIS APIs prevent input buffering by implementations
Created by: AlanRobertson
The AIS APIs are generally event oriented. And, this is necessary and a GoodThing. They also provide a file descriptor back to the application so they can use whatever method they want to be notified when new input comes in. And, this is also necessary and a also a GoodThing.
However, they do not provide any method beyond the file descriptor to determine of any events / messages / or input is pending.
And this is a BadThing.
As a result, it prohibits implementations from providing the highest efficiencies by buffering events for the client in the libraries on every occasion.
That is, if the client library sucks all the events associated with a file descriptor in, then the client may not be aware that an unread / unprocessed input is available. This will sometimes result in clients sometimes hanging.
We ran into this in real life in the Linux-HA implementation of the AIS APIs.
This software uses an IPC mechanism which is quite agressive in reading inputs into its queues, so that throughput is maximized and system resource usage is minimized.
As a result, any time it is asked about an IPC queue, they take the opportunity to read in any newly-arrived inputs into its queues. This code is modelled after standard device driver code which maximizes efficiency (avoids interrupts) by doing as much on each interrupt as possible.
Since there is no equivalent to an AreEventsAvailable() (or whatever) function, this input could not be observed by the client. And, since it was no longer in the system queue, it also meant that a select or poll operation would not be able to observe the new input.
Adding IsInputAvailable() call(s) to the API would solve this problem, and libraries would be free to read input from the system at any time.