DenkzeitWiki

Escape The Event Loop

• Escaping the event loop: an alternative control structure for multi-threaded GUIs by MatthewFuchs?
• Why XML is Meant for Java? by MatthewFuchs?
  
  
• http://en.wikipedia.org/wiki/Event-driven_programming
  • event loop
    • polling
    • interrupts
  
  
• http://en.wikipedia.org/wiki/Asynchronous_I/O
  • Processes
  • Polling
  • Select loop - checking some filehandler
  • Signales/Interupts
  • Callbacks
  • Events
  
  
• Boost application performance using asynchronous I/O

• PEAK.events
  • [Python-Dev] Minimal 'stackless' PEP using generators? - sheds some light on coroutines used for event-handling
    
  
  
• Why Events Are A Bad Idea (for High-concurrency Servers)

• Doing Work Without Threads

To be fair, there are good reasons for the popularity of the synchronous style. APIs that don't return until they've done what you asked them to do are usually simpler than the asynchronous alternatives. They require less code to use. The code is typically also a lot easier to read, because the flow of the code directly reflects the sequencing of operations; asynchronous code tends to have a somewhat fragmented structure. And of course sequential code is a lot easier to get right - doing everything on one thread in the order you want is much easier to do than trying to write code that handles events in whatever order they happen to occur, with whatever thread they choose to arrive on.

As for receiving data, that is initiated by the network card - when it receives a packet, it raises an interrupt. This causes the CPU to stop what it's doing and handle the interrupt. Exactly what happens at this point will vary depending on the exact context, but the important point is that the handling of incoming data is triggered by the arrival of incoming data. There doesn't need to be a thread waiting to receive the data. The data just arrives, and by the magic of interrupts, suitable processing ensues.

• Experiences with Coroutines and Continuations
  • MicroThreads? are special cases of CoRoutines
  • Full CoRoutines can jump between another, i.e. they not necessarily return to their callers.
  • Continuations: represent the state of the coroutine, but also have a specific instruction pointer in that coroutine. Conceptually, a continuation represents what could happen in the future of a coroutine if the continuation is called: i.e. the rest of the program.
    • In practice, a continuation looks like a function you call, but it’s more like a jump back into a coroutine that never returns. If that coroutine wants to return like a subroutine, then you have to call the continuation of the original coroutine making the call.
      
  
  
• http://harkal.sylphis3d.com/2005/08/10/multithreaded-game-scripting-with-stackless-python/
  • Interesting article on game-programming and actors/actions

Now instead of a tedious kind of state machine, you're writing an plain, ordinary function that sends messages to its peer and looks at the response, as though that were all synchronous, and it's so much simpler. Yet the execution underneath that isn't synchronous at all, because your computation is suspended in between your send and the response. It really does return every time it sends a message, it just starts up next time where it left off. [1]

• http://www.thescripts.com/forum/post115532-4.html
• http://www.thescripts.com/forum/post115854-27.html

• Windows Event loop and Message Pump?
  • http://blogs.msdn.com/oldnewthing/archive/2003/07/23/54576.aspx some C++-code
  
  
• Event-Driven Programming: Introduction, Tutorial, History
  • Homepage of Stephen Ferg