The FIFO System

The DD system is based on a set of fifos that are created and destroyed in real time. A process attaches to the DD system by creating a fifo from which he will read C structures describing the type and location of an event in shared memory. A process can become a producer by attaching to the INPUT_FIFO from where he will read C structures telling him the address of free space to copy an event.

Events are only copied once into the DD shared memory. After that only C structures (called fev for fifo event) describing the event (type, size, shared memory id...) are passed between the processes (i.e. written/read into/from the fifos). Once a process reads such a C structure from its fifo, the event ``disappears'' from the DD system until the process puts it back into the system. This allows modifcation of events (events can be compressed, merged or even deleted and newly created).
In the E787 implementation the fifo event fev is the following C structure:

 
		  typedef structure fifo_entry { 

		 		  int shmid; 

		 		  int dboff; 

		 		  int *p2da; 

		 		  int len; 

		 		  int ctl[4]; 

		 }  fifo_entry; 

where :

		  shmid 		 		 the shared memory identifier where the event resides

		  dboff 		 		 the offset within the shared memory

		  *p2da 		 		 pointer to the start of the event

		  len 		 		 length of the event

		  ctl[4] 		 		 array of control words (see below).

As it is not desirable that every process receives every event, a set of control words allow the routing of events directly to processes that ask for given event types. E787 uses the level 0 trigger bits as control words.

Processes can attach to the same fifo. In this case the events are shared between the processes. This allows to avoid bottlenecks by distributing the events between processes in a multiprocessor environment.

Fifos can be created and destroyed at any time. This enables e.g. user processes to attach to the DD system, receive a given number of events and then detach from it.

Four exceptions have to be handled: When a process reads an empty fifo, when a process wants to write into a full fifo, when the system runs out of shared memory segments into which to place new events and when ``something really bad'' happens.

• Reading an empty fifo:
  Every process specifies at initialisation time how the wants to handle this situation. He can either fall asleep until an event arrives or return with an error code or return with an error code and then receive a signal telling him, that an event has arrived.
• Writing into a full fifo:
  This situation is avoided by making the fifos deeper than the maximum number of possible events in the system.
• The system runs out of shared memory segments:
  This situation is identical to reading an empty fifo, whereas now the empty fifo is the INPUT_FIFO.
• Something bad happens:
  A demon constantly monitors the DD system and tries to detect and correct error conditions: E.g. if a processes crashes and doesn't detach from the DD system, he will be removed. Alternatively if there is a fatal error (i.e. the disappearance of shared memory segments or semaphores), the system is shut down as gracefully as it can be done.