This site best when viewed with a modern standards-compliant browser. We recommend Firefox Get Firefox!.

Linux-HA project logo
Providing Open Source High-Availability Software for Linux and other OSes since 1999.

USA Flag UK Flag

Japanese Flag


About Us

Contact Us

Legal Info

How To Contribute

Security Issues

This web page is no longer maintained. Information presented here exists only to avoid breaking historical links.
The Project stays maintained, and lives on: see the Linux-HA Reference Documentation.
To get rid of this notice, you may want to browse the old wiki instead.

1 February 2010 Hearbeat 3.0.2 released see the Release Notes

18 January 2009 Pacemaker 1.0.7 released see the Release Notes

16 November 2009 LINBIT new Heartbeat Steward see the Announcement

Last site update:
2019-12-12 23:48:49

issue id


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.

CategoryIssue, CategoryOpenIssue