On Feb 15, 11:43 pm, [EMAIL PROTECTED] wrote: > On Feb 15, 8:04 pm, [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
