Hairy brainstorm

[castironpi at gmail.com]

On Feb 15, 11:43 pm, castiro... at gmail.com wrote:
> On Feb 15, 8:04 pm, castiro... at gmail.com wrote:
>
> > 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?

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.