Interrupts, Signals, and Events.

Interrupts, Signals, and Events.

[Diogenes]

Lately I've been toying with using Linux epoll() and BSD kqueue() with some test code.

I've come to the realization that the Interrupt_Handler facilities, relying solely on Signals, just isn't going to work for some of my upcoming projects.

So I've been wondering if an abstract package(similiar to Storage_Pools) like "Ada.Events" or "GNAT.Events" would be a welcome addition to the Ada ecosystem.

It would allow developers to define their own event mechanisms without being welded to the Signal mechanism that is the current default for many compilers and runtime environments.

Also, why do so many Ada developers default to the "exception" mechanism for most events when so many of the events are clearly NOT exceptions. A key press in a text editor, for example, should not be considered "exceptional". Right?

IMHO we should start breaking these interrupts down into their own "classes" if you will, according to their intended purpose...

Events - Interrupts that are EXPECTED to occur, probably quite frequently, as a normal part of program execution.

Signals - Interrupts that are not expected as a typical part of program execution, but also should NOT necessarily be considered "abnormal" or "erroneous".

Exceptions - Interrupts that are not a normal part of program execution and are most likely an indication that something went wrong.

This would also allow the compiler(I suspect) to do more accurate checking and optimization of each class of Interrupt.

Just a rough idea. Not sure if it makes sense. But it at least SOUNDS like a good idea.

Thank you for your patience. ;->

Diogenes

Re: Interrupts, Signals, and Events.

[Dmitry A. Kazakov]

On 2017-02-27 20:26, Diogenes wrote:

> I've come to the realization that the Interrupt_Handler facilities,
> relying solely on Signals, just isn't going to work for some of my
> upcoming projects.

Well, signals is Unix specific stuff, other OSes use different 
mechanisms and nomenclature, e.g. traps.

> So I've been wondering if an abstract package(similiar to
> Storage_Pools) like "Ada.Events" or "GNAT.Events" would be a welcome
> addition to the Ada ecosystem.

How similar? Storage pool has a clear purpose to provide user access 
types in addition to built-in access types. There is nothing built-in 
regarding OS-specific synchronous and asynchronous interrupt handling. 
How would it be different to already existing Interrupt_Handler anyway?

> It would allow developers to define their own event mechanisms
> without  being welded to the Signal mechanism that is the current default for
> many compilers and runtime environments.

Now, event is a way different thing. Depending on the flavor, an event is

#1 a waitable object

#2 a marshaled object carrying some minimal data with it stored in a FIFO

Ada protected objects are perfectly suitable to implement either.

> Also, why do so many Ada developers default to the "exception"
> mechanism for most events when so many of the events are clearly NOT
> exceptions.

If event meant

#3 synchronous trap/interrupt (it usually does not), then exception 
would be exactly that thing.

> A key press in a text editor, for example, should not be
> considered "exceptional". Right?

That depends on the interface and the abstraction level. On the lower 
levels it is an asynchronous interrupt, that is how the hardware usually 
works. Somewhere above that it could be a synchronous interrupt. More 
stores above it could be #1, #2, anything.

> IMHO we should start breaking these interrupts down into their own
> "classes" if you will, according to their intended purpose...

They are already according to the mechanism involved. Synchronous vs. 
asynchronous is the major factor determining usage and behavior. 
Different frameworks choose one or another for keyboard.

E.g. GTK uses synchronous keyboard events (all GTK events are 
synchronous). Windows GDI uses asynchronous messages. Both approaches 
have advantages and disadvantages. Synchronous handlers deadlock. 
Asynchronous handlers live-locks.

Either is easily implementable in Ada.

> Events - Interrupts that are EXPECTED to occur, probably quite
> frequently, as a normal part of program execution.
 >
> Signals - Interrupts that are not expected as a typical part of
> program execution, but also should NOT necessarily be considered
> "abnormal" or "erroneous".

It is a useless distinction because expected or not both must be handled.

> Exceptions - Interrupts that are not a normal part of program
> execution and are most likely an indication that something went wrong.

They are normal per definition: anything that a correct program does is 
normal. If a program does abnormal things it is an incorrect program. 
[Incorrect programs can do normal things too.]

> This would also allow the compiler(I suspect) to do more accurate
> checking and optimization of each class of Interrupt.

Exceptions already have zero overhead if not occur. What more can the 
compiler do?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de