Hairy brainstorm

[castironpi]

Hold the future holds effectively nothing for single-threaded
programs; single-core PUs have reached the point of diminishing
returns of circuit size and IC design; thinking multi-threaded's the
way to go.

Recognizing that even in event-driven programs, order of execution is
important, what does a new thread for each event in a Gui TK look like?

 

[castironpi]

Hold the future holds effectively nothing for single-threaded
programs; single-core PUs have reached the point of diminishing
returns of circuit size and IC design; thinking multi-threaded's the
way to go.

Recognizing that even in event-driven programs, order of execution is
important, what does a new thread for each event in a Gui TK look like?

Caviat, an OS may design event notifications flows to return values.

Can an OS, speaking strictly abstractly, spawn a separate thread upon
an interrupt? ...-tion?

 

[castironpi]

Caviat, an OS may design event notifications flows to return values.

Can an OS, speaking strictly abstractly, spawn a separate thread upon
an interrupt?  ...-tion?

In Windows, events either come from one's main loop:

while( GetMessage( &arg ) )
DispatchMessage( &arg );

(DispatchMessage calls HandlerProc), or are a direct callback /of/
HandlerProc, registered with the system, by the system. Premise:
Order is unimportant. Add these APIs:

while( GetMessage( &arg ) )
DispatchMessageThdd( &arg );

Either: DispatchMessageThdd and the system call HandlerProc in "the
right" thread: an existing one, if the event is in a special sequence,
or a new one otherwise; Or, they always calls HandlerProc in a new
thread, and when order is important, one can synchronize.
Complicated, but distributed.

Messages can be disserialized in at least one case. Serial APIs
remain. DispatchMessageThdd raises the performance ceiling in the
abstract case.