[m463]

The thing is -- computers ARE event driven at the low levels.

Problem is most systems are designed to completely hide the event-driven nature of things.

The "nightmare to read, understand, debug and modify" is happily abstracted away and we have a nice safe environment to work with.

... and it then becomes much harder to support parallelism, error handling and responsiveness.

I think there may be a more nuanced solution.

[kazinator]

Not really.

Interrupts are really a polling mechanism: the CPU checks an interrupt line at convenient times and alters its control flow.

Most signaling depends on timing: based on what signals have been seen so far, some other signals must appear within a certain time frame. The new signals are blindly sampled.

For instance, if some device asserts some bus line that it's writing some data, then the data to be written is expected to then appear in some time window. The data lines will be sampled regardless of whether the device actually puts out that data. There is no "device has done it" event, and even the original write indication signal is basically polled.

If we look for a pure cause-and-effect relationship, it's hard to find. A device whose operation is altered by a signal is as much the cause for what happens as is the device which originates that signal.

[delusional]

I'm curious here. In my mind the computer is basically imperitive. It processes a series of instructions. It then happens to process multiple of such streams at once, but it's still essentially serial.

How is it event driven?

[fallous]

It's event driven in the manner of stimulus/response. A computer may process a series of instructions, but absent a loop it then finishes and does nothing without being told to process another series of instructions. Even within a listening loop it is essentially looking for "something to happen" and if nothing happens it NOPs, or does some basic house cleaning regarding the loop which is essentially the same. It is only when a stimulus occurs that the computer responds with a not-loop series of instructions.

[iainmerrick]

I suspect they’re confusing “event driven” with “interrupt driven”.

[m463]

Yes, interrupts and events are distinct.

Would it be clearer to say sequential vs asynchronous?

Or to say that interrupts are one form of event, but not all events involve interrupts.

[dalore]

Most computers have had more than one core and even additional cpu's like a gpu. Also things on the bus usually have their own processors. So things are happening at the same time, it might tick at the same rate that the bus allows but they communicate by events like interrupts. As far as I understand it.

[m463]

i/o, exceptions, system calls.. all these (usually) involve stopping the sequential flow of your program and doing something else.